April 25, 2014

All Posts Tagged With: agile

Agile Coaching Blog

What Big User Stories Could be Telling You

User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

Why User Stories Get Big

I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:

  • A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
  • A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
  • Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
  • And more…

Lack of Focus

The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.

For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.

The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.

Have Conversations

In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.

Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.

Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Scrum Meeting Success for Distributed Teams

In a previous blog, I discussed ways to make distributed daily scrum meetings more effective. This blog reinforces those ideas and provides additional tips to run successful scrum meetings with geographically distributed teams.

Productive, timely, 15-minute Daily Scrum meetings, remain a challenge. As many practitioners will attest, co-located Daily Scrum meetings are nearly as challenging for some of the same reasons:
- Meetings go beyond 15 minutes
- Not everyone has a chance to be heard
- Conversations wander into resolutions and opinion
- Impediments are not captured and addressed
- Others interrupt
And more…

Holding team meetings where members are not in the same physical or mental space is quite challenging, and it becomes more so when the team is geographically distributed. As I mentioned previously, the initial rule of thumb was to breakdown the daily meeting into small deliverables and then focus on each part of the meeting. The overall Definition of Done is the teams take ownership of the Daily Scrum meeting and use this as a foundation/basis. This idea has evolved into a goal for Daily Scrum meetings of having the team take ownership and management of their daily meeting. With this, we can create “Definitions of Done” for each part of the meeting.

For example:
Part 1: The team listens to each other’s ‘questions 3’ with no interruptions.
- Definition of Done: each team member has an equal voice to state their answers and be heard by their team members.

Part 2: The ScrumMaster reads the impediments/issues they recorded and the team adds, corrects and confirms the list is correct
- Definition of Done: the ScrumMaster reads off the impediments and has the team approve them

Part 3: The participants in the Daily Scrum meeting organize additional conversations around the Sprint and the results of the Daily Scrum Meeting the team.
- Definition of Done: the team members self-organize and work on the issues at hand and have these groups communicate what they did before the next scrum meeting, to the rest of the team.

When it comes to implementation there‘s a way to execute this process. For example:.
The meeting begins with one team member (initially the ScrumMaster) asking a team member the ‘questions 3’.
- The team member identifies the task and the story they are working on. They describe at a high level what they are doing and how much more time they need to finish.
- The team member then describes what they plan on doing tomorrow. If they will be moving to a new task, they should state which task.
- The team member then states what issues/impediments/ concerns they have about getting the work done or completing the sprint..
- Team member #1 then asks another team member the ‘questions 3’. This is a sure way to transfer ownership of the meeting to the team.

This is not a ritual. It is a basic pattern of action that can be used to start off a new team, orient new team members and get a team back into a rhythm. I have found that getting back on track is a lot easier if there is a simple base or foundation to structure and define roles. From there, teams can quickly self-organize…and it works well when things get stressful!

Roles and Actions for the Daily Scrum
ScrumMasters don’t run the Daily Scrum – they guide the team to run it themselves. Their primary focus is to collect the impediment list and get it approved by the Team. There should be a task on the task board regarding impediments for reporting the status of impediments.

Team Members individually and collectively run the meeting.

The Product Owner should be there listening and ready to answer questions immediately after the meeting closes.

Anyone who has committed to deliver something to the team during the Sprint must have a task on the task board and attend and answer the questions 3. This includes Product Owners, stakeholders, and management.

Guidelines and Techniques for the Daily Scrum
1) Turn the meeting ownership over to the team by having each team member ask another member the ‘questions 3’. Since there is no pattern or set order when one team member asks another, people on phones pay attention because they do not know when the questions will come their way.

2) The ScrumMaster is the servant leader, helping the team stay focused on the conversation, the task board, and the questions. It’s surprising how quickly the rest of the team picks up on this focus and brings the more loquacious and “off tangent” teammates back on track by asking “what task are you talking about?” Some teams go as far as including a protocol statement in their team charter stating all questions in the daily Scrum meeting begin with the user story and the task.

3) At the end of the first part of the meeting, the ScrumMaster, who may have been taking notes on the impediments, begins the second portion of the meeting by going over the impediment list to see if any were missed. This action reinforces that this meeting is for the team and that all issues are visible and noted.

4) The third and final part is a call for the issues to be discussed immediately after the meeting. Any team member, including the Product Owner may ask for conversations on story or task issues.

5) As soon as that is sorted out, the ScrumMaster requests that all decisions resulting from the upcoming conversations be communicated before the next daily meeting.

6) The daily meeting is closed and the conversations continue.


A Very Agile Thanksgiving – Using Personal Kanban

A Very Agile Thanksgiving
Using Personal Kanban To Plan Your Holiday Dinner


Thanksgiving is almost upon us. For many, this is a joyous time of celebrating family and friends and giving thanks. For others (like those preparing for the actual celebration) the long list of To-Dos can seem a bit overwhelming.

One of the easiest ways to cope with this stress is to start practicing agile at home and using Personal Kanban is a great way to get started. Below is a step-by-step guide to taking the list of To-Dos and turning it into something that may give you another reason to give thanks this November.

Step 1 – Set up your Personal Kanban board

If you’ve got a big blank space on a wall near where you’ll be doing the work preparing for Thanksgiving, that would work great. If you don’t have that available, you could use BigVisible’s SeeNowDo or one of the many web based Kanban Tools like LeanKit. If you are working on a tablet computer, KanbanPad.

The easiest way to get started with this is to create a board with 3 columns: Ready, Doing and Done.  If you are really trying to keep with the practice of Kanban, you’ll also want to create a Work in Progress (WIP) limit, at least for the Doing column. The idea behind this is to minimize the amount of things you are working on at one time. If you set a WIP limit of 2 in the Doing column, then it means you can’t be working on more than 2 things at any given time. (Ideally you want a WIP limit of 1, but if you are new to this kind of thing and still believe in multitasking, this may help you keep from trying to do everything at once.

And if you have people helping you with the work, you may want to set the limit a little higher.

Step 2 – Build your Backlog

Grab a stack of Post-Its and make a list of all the things you know you have to do in order to prepare for Thanksgiving. Put one idea per Post-It and place all of them in the Ready Column. This will serve as your backlog of work. You may find it helpful to order (or prioritize) the list of items. If you are going to prioritize the list, you may want to order the items based on what is the most stressful, what takes the most time, or what is going to be the hardest thing to do. You should also factor in some idea of the order in which these things will logically happen. For example, it wouldn’t make sense to prioritize a work item to “Clean the Dishes” so that it reaches the top of the list before you get to “Cook the Turkey”.

Step 3 – Working the Backlog

Once you are ready to get started, pull the top item(s) into the Doing column and begin working on them. If you have a WIP limit, you should only pull in as many items as the WIP limit allows. So, if my WIP is 2, then I can have only 2 items in the Doing column at any one time. If you feel like you need to get started on a new item from the Ready column, you’ll need to complete one of the items in the Doing column first.

Each time you complete an item, move it to Done. It may not seem like much, but you’ll be surprised at the increasing level of satisfaction you get each time you get to move something into the final Done column.

If you’ve got people helping you, they can take and move items as well (keeping to the WIP limit). The idea behind all of this is to limit the amount of things we are working on at one time, get one thing completed and then start on the next item. If you are preparing the Thanksgiving-feast-that-will-be- talked-about-for-generations, you’ve got a lot to do in order to get ready. Staying focused on one item at a time will help reduce your stress, give you greater visibility into exactly what is left, and also help you coordinate the work with anyone on your team.

Step 4 – Lather, Rinse, Repeat

Keep working your backlog until everything is done, moving tasks across the board as you make progress each step of the way. As you move more items to the Done column, you’ll find that the overwhelming pile of things you need to complete is rapidly taken care of, allowing you to spend less time fretting about what has to be done, and more time celebrating with your family members.

Some Tips for Trying Personal Kanban

You may be tempted to skip the WIP limits and just pull everything into Done. This is a tough one – especially if you feel like everything has to be done anyway. Trust in this system, if only as an experiment. It’s been used successfully on projects far more complex than Thanksgiving and it really does work…if you let it.

If you have the ability to set up your “board” space near where you’ll be working (like your refrigerator), you will find it helpful to have it out in the open and easily accessible as you make progress. It will also let others know what you are doing, and hopefully they’ll join in to help.

One of the things I learned from my Personal Kanban experiment earlier this year was that it taught me how incredibly inefficient I have been with my work. If you find the same, just make a note of what you learn and keep it for after Thanksgiving. Once the dinner is over, the dishes are clean and you’ve recovered from the massive intake of turkey, cranberry sauce and pie, take time to hold a Retrospective. If you had helpers for the preparation, include them as well and talk about what you learned during your Personal Kanban Thanksgiving. Try to find some lessons you can take away and improve upon when you begin preparing for your next big holiday meal.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Practical Systems Thinking: Don’t Let Inertia Become the Constraint

Congratulations! You’ve gotten to the fifth step in the Five Focusing Steps of the “Theory of Constraints”. That means you’ve broken the constraint in your system!

But, your work is not done. As a matter of fact, it’s just starting. You see, once you break a constraint in your system, a new constraint will always emerge. Yes, you elevated the throughput of your system, but, as you’ll see in this segment, you must be relentless about breaking the constraints that continue to emerge.

In Eliyahu Goldratt’s CD Series, “Beyond the Goal”, he discusses the dangers of inertia and what he means when he says ‘don’t let inertia become your constraint’. He’s referring to Internal Inertia, something we must combat against within our own team(s). In other words, don’t become content or complacent.

But, beware! There’s another form of inertia, one that is much more difficult to identify and overcome: External Inertia. It’s the “inertia” caused by the set “rules” within your organization, the “that’s the way we’ve always done it” mentality that may resist the changes you implemented when you broke your constraint. The challenge with these rules is that they were good, and even helpful, at one time, so people are reluctant to give them up. Teams realize that these directives were put in place to help the organization be more effective based upon the way it was operating. But now, they may not realize these precedents are no longer relevant since we’ve changed the game and the way we think about the system.

Check out this video as I expand on the concept. And if you missed any of the previous installments of “Practical Systems Thinking”, check out the “You May Also Enjoy” section below this clip.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Practical Systems Thinking: Subordinate to the Constraint

Subordinate to the constraint?? That doesn’t sound right! But that’s the third step in the “Five Focusing Steps” of the Theory of Constraints. It’s possibly the most challenging part of the process because it seems counter-intuitive and requires tremendous discipline when implementing it. Does that mean we’re “hitting the breaks” in this process? After all, “subordinating to the constraint” means that if you want to get more work through your system, you essentially have to do less.

In this fourth installment in the Practical Systems Thinking series, I’ll show you how introducing too much work into your system will cause inventory build-up in front of your constraint which, in turn, has a detrimental effect on your system. I’ll also show you how 100% utilization of resources in front of your constraint will cause you to lose your ability to exploit your constraint, ultimately reducing the throughput of your system.

Miss our previous installments? Check them out below, under the “You might also enjoy section”.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Practical Systems Thinking: Identify the Constraint

Do you know where the constraint is within your system? Are you aware that you have one?

Our first video in Practical Systems Thinking talked about having an appreciation of your system. All systems have constraints – including software development systems. Whether you are doing Scrum, Kanban or waterfall, there will always be a constraint. It’s the constraint within your system that determines your system’s throughput. Therefore, optimizing anything else other than your constraint will not increase your throughput.

So where is the constraint within your system? Are you actively working at breaking that constraint? Or are you unaware that you might be focused on improving non-constraint components in your system that will not increase but decrease your throughput?

In this video I introduce the “Five Focusing Steps” of the Theory of Constraints for breaking the constraint within a system. The first step is being able to identify where it is in your system.

I’ll show you how an agile task board can be used to identify the constraint within your system. I’ll also show you that just relying on burn down charts is not enough for effectively managing the work in your sprint.

After you have identified the constraint in your system, you can then go about breaking that constraint.

Next week’s installment: Exploiting the Constraint. We will talk about step #2 in the “Five Focusing Steps” for breaking the constraint in your system.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Practical Systems Thinking: An Appreciation of the System

When you hear the term “systems thinking”, do you roll your eyes? Does it seem irrelevant to what we are doing in software development? I used to think that way, that Systems Thinking was just an academic exercise and all theory, not practical to what we do on a daily basis. The concepts seemed unrelated or unnecessary to what we do – but I’ve since learned it isn’t.

Software development processes are, in fact, systems working within a larger system – the organization. Learning to be mindful of this has helped me adapt the components of these systems and the interaction between the components to make them more efficient AND effective. In other words, I’ve since learned that Systems Thinking is very practical and applicable, especially in the world of software development.
It’s my intention within this video series on “Practical Systems Thinking” to show you how systems thinking is applicable in our daily work in software development.So stay tuned, each post is going to continue to dive deeper and deeper, ultimately leaving you armed with a new set of systems thinking tools to use in your day to day work with agile.

In this first video, I’ll introduce you to the importance of component interactions within a system and how agile optimizes them.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.