Project Management Archive

0

My Personality Assessment

checklistI recently took a personality assessment for LeadingAgile.  I didn’t know what to expect.  I wasn’t happy with all of the choices that were presented to me but I answered all of the questions the best that I could.  Below is the outcome of the assessment.  When I showed it to my wife, she laughed and nodded her head. Regardless if this was a partial result or the full readout, they kind of nailed it.

Strengths:

  • Assumes the weight of the world on his shoulders
  • Probably more good than bad, but his focus in personal goals and relentless intensity can make for a person who will execute at a high level.
  • His quick decision-making and ability to change direction is helpful to inspire confidence.

Opportunity:

  • His temper and emotions get the best of him at times and can be explosive.
  • He tends to be focused on going solo in his role and probably doesn’t share much.
  • He’s super willing to take on tasks or responsibility which may weigh him down especially as he’s not the most organized person either.

Final Take:

  • There’s A LOT going on in his life and he’s not taking time to stay balanced.
  • Something is new or changed in his life that is causing him to be really stressed and not have time to exercise and is causing him to be really short and harsh in his reaction and interactions with others.
  • He’s a really strong individual who has a ton of quality strengths, he just needs to fix whatever is going on with him and build a way to manage the stress and aggravation that is present.

I’ll have to give these these people credit.  They pretty much nailed me.  I am very goal orientated and do have a relentless intensity.  When someone tells me they are doing their best, my internal monologue says something like “Don’t do your best. Do better”.  To provide clarity around “he tends to be focused on going solo”, it should be written as “if he doesn’t feel confident others will do something to the level he expects, he’ll do it himself”.  I do take on a lot of responsibility and lack organization and therefore use a personal kanban for everything.  I think the misunderstanding there is I enforce my WIP limits.

Knowing my limitations makes me very anxious.  I’m working on balancing things out a little by running more, which I did this morning.  My long term goal is having a stable velocity and sustainable pace.

 

Has anyone else out there taken one of these assessments?  What do you think of them?


0

You Need More Process and Tools

processEven in an environment where you have a single, ideal, co-located cross-functional team, I believe you’re going to need processes and tools. The more complex and distributed your organization, the more processes and tools you’re going to need. Doesn’t sound very agile does it? Well, get over it. You’re going to need processes and tools to enable individuals and interactions. If you can’t sit in your chair and make direct eye contact with everyone on your team, you need more processes and tools. Hell, even if you can see everyone, you’ll still need processes and tools. What is Scrum? A process framework. What is a team board? A communications tool.

Context

I’m not dismissing the Agile Manifesto. I do prefer individual and interactions over processes and tools. I’m just trying to establish some context. Most of us don’t work in that ideal agile world. Rather, we have to operate within a series of non-ideal organizational constraints. Most people are sold on the idea of Agile. The values and principles resonate with us. But my job (and LeadingAgile) is to understand the goals of an organization and help them reach them.  We start by laying the foundation for an agile enterprise by forming teams and installing a Lean/Kanban based governance model, but maintaining focus on longer term planning, risk management, and dependency management.

Current State

Before laying the foundation, I look at their current organizational structure, I look at their current governance (processes) and I look at their current metrics to see how good that structure and governance is working out for them.

Future State with Process and Tools

Whatever the future state looks like, I expect two things to help get us there.

1. We need to provide clarity by making process policies explicit.
2. We need to demonstrate incremental improvements by using tools.

Do you agree with me? Maybe you disagree with me. I’d love to read your feedback.


Image Credit: Pictofigo

Tags: ,
0

Eliminating waste with reusable story cards

When coaching clients who use physical team boards, I’m seeing more of them gravitate away from pins and painters tape and toward the use of magnetic whiteboards, sticky-notes and index cards. I see them making a substantial upfront investment in the whiteboards and then again with magnets. If the magnets are too costly, I see them make the lessor but incremental investment in painters tape, post-it notes and paper index cards.  So, how do you eliminate the waste of the disposable index card or post-it note?  Just combine the magnet and card!

storycards

To be clear, I’ve got no skin in the game with this company. I’m not being paid to write this and I’ll make no money if you purchase their product. I just think this is a product that you’ll like and I think it’s worth writing about.

Though I usually don’t do product reviews, I found the product from Story Cards particularly compelling.  I asked them to send me a few samples so I could see for myself if this is something I would recommend to others.  Well, it is!

If you purchase a group of these reusable story cards, say goodbye to sticky-notes, painters tape, magnets or pins.  They come in four colors: blue, red, green, white.  These reusable story cards are made of a flexible magnetic material on one side and whiteboard material on the other.  They peel off easily but have enough grip that they won’t blow off the board like post-it notes do.  Great idea! Thank you storycards.co and day5labs.

0

Could a Patent Troll Kill Agile?

patent trollPatent Trolls

I don’t personally own any patents but perhaps I should reconsider.  If you own a patent, you can sue people for infringing on it.  You don’t have to actually create anything valuable. You just sue people and make money.  You’d think it sounds crazy but it’s happening!  People known as “patent trolls” are buying patents for the sole purpose of suing others.  One guy in Texas owns a patent and sent out 9,000 letter demanding $1000.  The violation?  He claimed to have patents that cover any networked “scan-to-email” function.

Patent That Could Kill Agile is for Sale

On December 8, Penn State is looking to sell a few patents it owns.  One of the patents for sale is US Patent No. 8,442,839, entitled “Agent-based collaborative recognition-primed decision-making.” The lead inventors are PSU professors John Yen and Michael McNeese. The patent essentially describes different ways that people work together to solve a problem.

Patent Abstract

Collaborative agents for simulating teamwork (CAST) are provided with a recognition-primed decision (RPD) model, thereby enhancing analysis through linking and sharing information using knowledge and experience distributed among team members. The RPD model is integrated within a CAST architecture to the extent that agents can proactively seek and fuse information to enhance the quality and timeliness of the decision-making process. The approach, which is applicable to both human assistants and virtual teammates, can approximately track human’s decision-making process and effectively interact with human users…

Thoughts

So, at the low cost of $5,000, you could theoretically buy the patent and then sue anyone using a collaborative agent (could be software or even physical boards) that helps people make better decisions and share information with team members.  Essentially, you could require all Agile teams to pay a licensing fee.

Questions

  1. Should Agile Alliance, Scrum Alliance, PMI, or some other body buy this stupid patent?
  2. Should VersionOne, Rally, and Microsoft join forces to share this patent?
  3. What would you do?

 

Image: Pictofigo

 

Tags: ,
0

Time to Replace Backlog Grooming

The Problem

backlog groomingOver the last few years, I’ve worked with numerous teams. One thing they all struggle with is backlog grooming.  They all know they need to do it.  Unfortunately, they all seem to struggle with when to do it or who should do it.  The most interesting struggle with backlog grooming happened two years ago.  The “story time” meetings took place at the beginning of a month-long sprint. The manager stated, the work to be completed and delivered during that sprint had to be refined within the same sprint.  This helped explain why the team thought they needed month-long sprints.  When I asked why they would try to refine work the first two weeks of the sprint and then complete that work the second two weeks, you know what their answer was?  “It said to do it like that in the Scrum Guide!” After I clarified their misunderstanding, we established a cadence to continuously mature the backlog.  A rotating selection of people would participate in the scheduled meetings.  We would reserve capacity from each sprint to get that work ready for future sprints.  The team was able to shorten their sprints to 2 weeks.  They more than doubled their delivery rate without increasing defect rates.  With that as an example, over the last few years, I have evolved my practice of backlog grooming.  Let’s look at some key dates in the evolution of backlog grooming.

Evolution of Backlog Grooming

2005: “grooming the product backlog” is mentioned by Mike Cohn on what is now the Scrum Users Yahoo Group;

I always have teams allot some amount of time to “grooming the product backlog” to make sure it’s ready for the next sprint.

2008: A formal description of “backlog grooming” is given by Kane Mar, under the name Story Time, and recommending it as a regular meeting

I call these meetings “Story Time” meetings….Although they are not a formal part of Scrum, I’ve found that Story Time greatly improves project planning and reduces confrontational planning meetings, which are all too common for many teams.  A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work.

2011: The practice of “backlog grooming” is called “backlog refinement” and promoted to an “official” element of Scrum with its inclusion in the Scrum Guide

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

2014: Derek Huether from LeadingAgile evolved the practice of backlog grooming with one of his clients, to allow the practice to work better at scale, calling it a “Progression” workshop.

When operating at scale, my client deals with different problems than a standard Scrum team.  They’re dealing with separate lines of business. They’re dealing with multiple delivery teams for each line of business, to include external vendors. They’re dealing with a portfolio roadmap that has annual plan items and budgets. Our strategy encapsulated the entire product delivery value stream, while ensuring we had enough architectural runway. We progressed work to be consumed by delivery teams, via a series of workshops.

Progression Workshops

Our progression workshops differ slightly from the story time meeting detailed by Kane Mar and the refinement meeting mentioned in the Scrum Guide.  Counter to Story Time, we don’t invite the entire team. Instead, we have elevated the workshop to a group some have come to know as a Product Owner (PO) team.  The group of people within the PO team will vary, depending on the line of business.  Yes, there will be a Product Owner (Product Lead) and facilitator, but from there we’ll include the development lead, testing lead, and an architect.  We’ve found two key challenges when operating at scale. First, is there a well defined backlog that is ready enough to be consumed by different delivery teams?  Second, is the work being queued up to the delivery teams free and clear of other teams.  That is, have we decomposed it in such a way that we’ve minimized dependencies on other teams? Beyond that, in order to achieve some degree of architectural runway, we continually refactor existing platforms. Architectural changes are not only made incrementally but we require an architect to be present at every progression workshop.

Counter to the Scrum Guide, I’m not going to be proscriptive as to how much capacity the PO Teams do/should commit to progression workshops.  The goal is to have enough work ready for delivery teams to consume for a few sprints.

When progressing work, we do expect some artifacts to be generated, to contribute to the teams understanding of what will be developed, tested, and delivered. Below is a partial list of potential artifacts. To be clear, we do not expect all of these to be generated.

Potential Deliverables

  • System Context Diagram
  • Dependency and Risk Work Items
  • System Architecture Guidance Acknowledgement
  • Use Case Diagram and document
  • Business Process Flow
  • Known Business Rules
  • High Level Technology Alignment
  • Architecture Backlog for Planned Work
  • As-Is Data Contracts
  • Feature Work Items Assigned to Delivery Team
  • Feature Business Value and Acceptance Criteria
  • Feature Stack Rank
  • Test Strategy

So, that’s the high-level view of the Progression Workshop.  Most of the time, a feature will require two or more progression workshops before work is ready to be consumed by a delivery team.  Once features progress to a defined level of shared understanding, the delivery teams assist in the decomposition of features to user stories.  In this way, work is decomposed to the right level of detail for each delivery team.

I’m curious, how have you scaled feature development and backlog grooming in your organizations? What mechanics outside of the standard Scrum process have you found useful to refine work to be completed by delivery teams?  Have you evolved Story Time or backlog refinement?

Image Credit: Pictofigo.com

Tags: