Constant Change

So that we can easily find ways to constantly improve while collaborating effectively and sustainably, I like kanban as a tool which shows what constrains transforming concepts into cash. I believe it allows us to see the whole system and our part in what to do to help in the transformation of the system into a better one and our ideas in to innovation. It seems to me there would be greater benefits for all involved.

For software a kanban tool must be highly visible, with a policy to strictly limit work in progress and a policy to only accept work when there’s capacity. To be effective, it requires consensus on these policies from the people involved.

Kanban is a Lean way of saying, “I trust and respect you”.

Aaron Agile, Kanban, Lean

I recently received an email from a senior-level manager, who raises a valid question about all the meetings associated with Scrum. This particular instance of Scrum has over 50 people working in more than one locale. When yet another meeting was created, he raised a valid question:

90 minutes every week for backlog hygiene? And that is on top of all other scrums, scrum of scrums, business reviews, can we ship, planning etc. meetings and scrums? I am getting seriously concerned about our state and efficiency. If we need to spend 90 minutes on this weekly, than, IMHO, someone is not doing their job. Looking forward to find out more.

My answer:

It’s true, this is a lot of time to spend together planning what we are building for this product. Are you familiar with the book, “Death by Meeting“? Essentially, a short daily meeting (15 minute standup) should focus on the daily plan (3 questions). The longer the meeting, the further out we’re looking. Meetings should have a very specific purpose, stick to it, start on time and finish when the purpose is reached. In Scrum, all meetings are finished when they hit the time-boundary (aka time box) as well. We endeavor to reach the objective before hitting the time boundary. Scrum-of-Scrums (SoS) is a little exceptional as you’ll see.

Let’s look at all the meetings in our Scrum.

-Daily stand-up. 15 minutes max. Only pigs are allowed to speak.
Single team daily coordination. Answer 3 questions.
1. What did I complete yesterday?
2. What am I planning on completing today?
3. What’s in my way of completing work?
We stand up to keep it short.
http://aaron.sanders.name/agile/what-if-the-standup-is-ended-on-time-but-not-everyone-spoke

-Daily SoS. Meta-stand-up. Inter-team coordination.
First, answer 4 questions. 15 minutes max and again, only pigs are allowed to speak for this part.
Scrum Master and Product Owner for each team required, other team members are optional as needed and/or interested.
1. What did our team accomplish yesterday?
2. What is our team going to accomplish today?
3. What is in our team’s way?
4. What are we about to put in another team’s way?
Then, we review all the obstacles on the board. Reporter confirms removal of existing ones. Decide how to remove the ones added today. Old obstacles are scrutinized.
Last, we walk through the Air Traffic Control (ATC) board and ensure it reflects reality. If a problem is detected, a plan is set to address it.
This meeting is the only one without a time boundary. We stay in the room until all goals of the meeting have been addressed.

-Weekly backlog hygiene
Keep the backlog in front of the Scrum teams by 4-6 weeks (2-3 Sprints).
+ Review meeting agenda and ask if any item for end
+ Review customer and user input about the Product
+ Review arrangement of the stories in themes and goals.
+ Write new stories, themes and goals. Remove old and wrong ones.
+ Review and update acceptance criteria currently known.
+ Prioritization
+ Team added agenda item, wrap-up.
Add new stories, keep the top prioritized. Look at the bigger backlog map. This will become the release planning mechanism. 90 minutes does seem long right now. Prioritization is not an easy endeavor. I would also like to enhance understanding of the User Story and examine the ones being added together. Some are coming in from user interviews. More are likely with Customer Support involvement. There are some interviewing-like ways to create them, so that eventually the customer/user can write them for us themselves. The time will also be needed later, once the teams pick up value delivery. All of this will intensify to stay in front of the progress we make.

-Review and Retrospective (aka Reflection)
Every 2 weeks we review the current working software with the customer, showing User Stories the Product Owners have accepted on their behalf. We then ask *them*, can we ship this to you? The answer will influence the backlog, too. The teams then gather and go through a retrospective to ask themselves, how did those last 2 weeks go and what would we like to change and experiment with to find improvements and innovation?

-Planning
We are now planning as we go at many different levels, so that is much less disruptive to the teams. For the pigs involved who are busy creating value, it is an impact of 15 minutes daily, and 2-4 hours for one day every couple of weeks. We are meeting so that they can continue to do their job of creating the actual Product.

-and more!
There should also be monthly meetings to look at the next 3 months, and quarterly meetings to look at the next 4 quarters, and yearly meetings to look at the next 3 years. That last one may be a 2-3 day off site.

http://leansoftwareengineering.com/2007/11/14/planning-a-month-or-less-ahead-is-not-enough/

This is a complex, adaptive system with emergent properties. The system is continuously running at a sustainable pace, with value flowing through it from concept to cash. We need constant feedback so that we may inspect this system and ensure we are adapting to the best of the emergent capabilities. The concepts are captured as User Stories, and when we release it we determine the market value, when we start getting revenue from the Product. Along the way we keep our customer/user involved at every step and invite them to attend any meeting. Except the Retrospective, which is for the pigs.

The ATC board shows all stories in progress for all teams. It includes the top of the backlog in a stack-rank buffer for teams to accept work from when they have delivered something and have capacity (below the story point WIP limit).

There are more than the 4 meetings mentioned in the book: stand up, SoS, review, retrospective, can we ship?, planning, backlog hygiene. The longer-term Agile strategic meeting is not yet in place. How else should I address the concern? Is there too much mixing up of strategic goals in the weekly tactical backlog hygiene meeting? Should that be pulled out to the monthly strategic meeting? What should be in the tactical one, then? What could be removed from a meeting, or a meeting itself? How would you redo these to be more effective?

Aaron Agile, Kanban, Scrum

After a few months working with a client, a WIP limit was introduced on story points at the latest planning meeting. When we started I said, “The good news is, you no longer need to track hours remaining. The better news is that you may never have to have this type of meeting again.” Here’s a nearly verbatim email from senior management, after planning.

We concluded the sprint planning today with a stack ranked backlog based on work folks did over the last couple of days (to get it prioritized). The sprint planning went well, all teams are “fully loaded” for the sprint except for Team-1. Here are my observations, anyone on this thread, please feel free to pitch in:

Team-1 was at ~(x) points, and the max per sprint is (y), so they could have taken more user stories. We went down the backlog and the next 6 or 7 required [special-skilled work only a couple people can do and they were] already maxed out (…) for this sprint. Further down the backlog were [feature groups for another team] related stories and since [those feature group] teams were max’ed out, we just stopped.

So, does this mean that Team-1, once done with their user stories, are going to start twiddling their thumbs? Maybe, but first, they HAVE to help other teams:

• with tasks
• with user stories
• help QA in testing to get the stories to the done state
• remove blockers from the blocker board (and we have identified new blockers that are slowing us down per the retrospectives)
• and basically help in any way shape or form move the stories on the board to the done state.

If all of the above is exhausted and there is really nothing else that Team-1 can do to help the current “in-flight” user stories across teams get to the done state, then, yes, they will be twiddling their thumbs and we would have identified a blocker that we need to address. Otherwise, we continue to push forward.

Do you think the new WIP constraint and attitude will help? Will there be an increase velocity and in quality of delivery, in your opinion? How about the effect on sustainable pace, or collaboration? Please comment below and I’ll provide my own opinions in following posts.

Aaron Agile, Kanban, Scrum

This was made awhile back and then sadly, the content was lost and only the effects played. With the help of my good friend Keith, the content is back! Alright, we’re back on with the Kanban.

Aaron Kanban, Quotes

If you track them electronically, some of the process changes, as many APLM tools allow for issue tracking. Hopefully, the intent and result still make sense.

Blocker Board
Always preferring high-touch and visible information radiators to track items, I tend to make a physical blocker board for teams I work with. Why do I call it a “Blocker Board”? It alliterates. I am finding it to be a problem to call it this. Perhaps I should change it to an “Obstacle Catcher”, or something that doesn’t make people think the sky is falling, just that we’re hunting for the system constraint.

Reviewing obstacles
Hopefully the obstacles are being removed quickly, and reviewing all obstacles identified during stand up lets the team verify the ones which have been removed. Having the requestor on the card lets that person verify the obstacle is gone. For the new one’s added, adding the day’s date, lets the team understand how long it took to remove, when verifying with the requestor. This review also gives a moment for people to think if they know (or want to admit to) another obstacle in the team’s way.

Obstacles are non-debatable
Having a working agreement that nobody can debate when someone states the fact they know of an obstacle helps ensure people feel comfortable bringing things up. If it is pushed off as, “not really an obstacle” or, “not an obstacle yet” can be very deflating to someone and cause them to resent mentioning it. Even if the requestor does convince others and writes it up, they may feel apprehensive that it will truly be removed.

Obstacles must be removed immediately
Having another working agreement that everyone should endeavor to get obstacles out of the way immediately, helps the morale of the team. Obviously, this allows the team to be as productive as possible. Removing obstacles immediately builds trust within the team and with management, increasing the camaraderie and expanding the notion of who is on the team. Immediate removal motivates the team, increasing respect by dealing with issues brought forth, without questions asked.

Avoid assigning owners and due-dates
Some obstacles take some time to be removed, even when endeavoring to have them gone by the next day. Assigning owners and due dates is a threatening stance. This is doubly true if obstacles are shot down as really existing when initially mentioned. Assigning one owner, especially at stand up in front of the team, implicit blame is laid on this person for having a problem. The date can only be a guess, and is now given under duress, if it is also in front of everyone. Date assignment allows the person to procrastinate on it, or use it as political leverage. It is stating that the team is fine allowing an obstacle to exist, and slow down the system. For political leverage, it is saying that I will not remove this obstacle, until you do something on my behalf. With the date being a guess, what happens when it comes up and the obstacle is still around? How much are you allowing someone to “game the system”? Assigning owner and due-date erode the sense of team and of collaboration. Avoid this, no matter how much you may feel it is the right thing to do.

If all else fails, prioritize obstacles
When the rate of obstacle removal is less than the rate of obstacle identification, there is yet another obstacle in the way. It might be incredibly difficult to find. In the mean time, prioritizing the ones that are identified helps find the greatest one for the most people. This may be close to, or a symptom of, the system constraint.

Finding the system constraint
Somewhere in the system, there is a very large obstacle, causing a bottleneck that could potentially be jeopardizing success, destroying morale and causing most of the stress. This is the team’s most significant impediment. This constricted area is the system constraint, and is where work passes through at the slowest rate. Having the practice in place of including the date added shows which ones have been around the longest, pointing the way. Agreeing to remove them immediately adds to the significance of obstacles that won’t go away. Prioritizing obstacles will also help identify symptoms of this constraint, and maybe even the constraint itself. Adding the requestor allows the organization to recognize the person who found this constraint, and reward them along with those who removed it, for helping to bring the team to a greater level of performance.

Removing the system constraint
Theory of Constraints explains it thus:

1. Find the system constraint
2. Elevate it (highest priority)
3. Subordinate everything else (nothing is more important)
4. Exploit the constraint (get rid of it for now and forever)
5. See step 1

Eventually, the largest obstacle which cannot be removed is found. Keeping this part of the system on a regular cadence and knowing it cannot go faster, makes it the heartbeat of the organization.

Aaron Agile, Kanban, Lean, Scrum

If there are multiple teams working off of one Product Backlog, how best to reflect and close the iteration? I see these choices:

choice 1:
one review per team
one retrospective per team
one consolidated review for everyone at end

choice 2:
one consolidated review
one retrospective per team

choice 3:
one consolidated review
one consolidated retrospective

I have a bias to the last choice, if space is not a factor. What is yours? Do you prefer another way to coordinate these meetings?

Here are my definitions for these Scrum ceremonies.

Sprint Review: Story time.

Only stories which are DONE and accepted by the product owner as matching the criteria are reviewed. Any and all questions are answered until the time-box of the meeting lapses. Priority is on reviewing all the DONE stories and celebrating success. Questions are parked and answered last.

This is a look at what value was created(the software+artifacts) within the last iteration for the Customer and with them present. Outcome should have immediate influence on the product backlog from the Customer. Typically, items are added and some removed. Usually there is at least a little re-sort of priorities.

I am lumping stakeholders, users, product owners, and other business people together as Customers.

Preparation for a review should be no more than 4 hours.
———————–

Sprint Retrospective: Not a bitch fest, and nothing died.

Longer release-level retrospectives are not a post-mortem. Good retrospectives last awhile and are very interactive. Great retrospectives have the 5 stages as listed in the Derby and Larsen book, Agile Retrospectives, as listed on Diana Larsen’s blog. It’s also in my slide deck.

A look at how that value was created (the process+practices) and ways to apply learning. Outcome should have immediate influence on working agreements and best practices.

With smaller groups, the line blurs between the end of the review and the beginning of the retrospective, except that all the chickens are kicked out, with the exception of the Scrum Masters and Agile Coach.
———————–

I start to think of all these types of meetings as review, and have recently heard the term reflection as a way to link them. Types could be: software, artifacts, process, operations, best practices, releases, roadmap, vision, and on and on. All on a syncopated cadence.

Do you agree with these definitions? How do you like to go about them?

I also would like to mention that these ceremonies I think are necessary no matter the process, and ensure their presence in any Kanban system a team I am coaching may be using.

Aaron Agile, Kanban, Scrum

Available from Karl’s blog for download. The session went well, everybody returned for the second half from the first half. I really enjoyed the simulation at the end, although we ran out of time to fully go through it. If you happen to use it, would you contact us and let us know how it went?

Aaron Kanban, Lean

As Karl Scotland noted, we will be presenting a session on Kanban, Flow and Cadence (KFC) at the Agile Conference this year. This will be Thursday 7 August from 8-10 and then 10:30 to noon in the Essex Ballroom as part of the Breaking Acts Stage.

This workshop explores three important Lean concepts – Kanban, Flow and Cadence (KFC) – which can be combined to generate a more pipeline-based approach to software development, as opposed to the more common timebox-based approaches of more traditional Agile methods. The presenters will describe their experiences implementing these ideas at Yahoo! and explain the concepts using examples, simulations and games. In addition, because this is a new and emerging way of working, there will be an opportunity for discussion between the participants about how the ideas might be applied in their own situations, in order to advance the art.

Aaron Agile, Kanban

For me, it’s all about getting the backlogs together and putting strict limits on WIP. It is a mess to find a bottleneck, or get to done, when too many things are in flight. Remember: there is one expedite slot to override WIP, but only one.

Two ways to limit WIP:

1. With the value stream mapped, look at the resources within a certain step and ensure there are no more slots than people in that step.
2. If there is an inability to get the value stream map, or while you’re going there, write a sticky for the name of each developer
   1. With all the things in flight, have a person put their sticky name on the WIP
   2. Have them move their name to whatever they are working on
   3. Don’t allow more things to be allowed in to WIP until there is no way they can put their name on something
   4. Only allow for one WIP per person
   5. Cut the WIP slots in 1/2 for pairing

If you’re trying to enforce pair-programming, or otherwise get cross-functional and more collaborative teams, limit WIP to half the number of developers. There should be a minimum of 2 slots for any one step in the process.

In throttling down in this way, and trying to get a handle on what’s in flight, make this request:

Put your name on what you’re working on
Nothing to work on? Ask if you can help someone else.
Don’t have the right skills for that? Find the bottleneck and work to release it.
Don’t have the right skills for that? Pull in work from the fixed queue.
Don’t have the right skills for starting anything in the queue? Ask the PO if there is anything lower priority to work on.
They don’t have anything? Go find other interesting work.

Aaron Agile, Kanban, Lean

A lot of popular folks come to Yahoo! and hang out. There are experts, authors, musicians, luminaries, – giving talks, running workshops, attending conferences, performing, and being a presence on the campus.

Our own group has had people in. I’m not sure who they all are. I hear there was Mary Poppendieck, who’s suggestion of eliminating waste may have been interpreted by a few as meaning some roles could be considered redundant. Seems a shame.

Since I’ve been around, there has been two people we’ve brought in. The first was Jim Coplien, who shook things up a bit. People are still referring to his presentation on agile architecture. We have it on video some where. I wonder if I can make it public? Worth finding out and better than me writing about it now.

Today David Anderson came in, and talked about industrial-strength, agile complimentary, product development system. This system is based in the Theory of Constraints (TOC), where customers pull value through the system. It takes advantage of mathematical fact and scientific backing in queuing theory and Little’s Law. The system is monitored real-time with an ever-changing visual board of all work in progress. Product is developed in a cadence, where success happens with enthusiasm. David calls it a Kanban System for Sustaining Engineering, and with a subtle change, it is a system for software engineering.

Slide Deck in the video

Aaron Agile, Kanban, Lean, Yahoo!