AgileIQ Blog

Agile User Stories Exercise: Walk the Dog

  

 Email Article  

Tweet  

  

by Dhaval Panchal

This is a simple technique with a marketing twist to its name. This title came to me while coaching a team that was struggling to behave cross-functionally and were paralyzed at delivering working software at the end of their sprint. It is a simple mental discipline that I have often used in crafting good user stories and I wanted them to walk their user stories with me.

Everyone is not an expert at analyzing business requirements against technical complexity, but most have had practice walking a dog. So lets ‘walk the dog’, plus this is much cooler than ‘lets walk the user stories’.

Metaphors only go thus far, but a cool title goes much farther. For me, a fancy title, acts as a trigger that allows me to break from the ongoing chain of discussions and engage in an exploratory exercise.

I have used this technique a few times to address primarily two types of challenges -- here are these stories:

Stories ‘not-done’ at the end of sprint

This team was formed of team members that were experts at their part of the code. This was their second sprint as a team and they were struggling to cross-train. To their product owner’s credit, he was creating user stories that were truly vertical slices of functionality that represented end-to-end implementation of features. Their main challenge was that in their two week sprints they were unable to meet ‘definiton of done’  (fully integrated and tested) on these user stories.

In response the team was asking the product owner to further split these user stories in two to three horizontal slices that could be integrated in later sprints. The product owner, was rightly pushing back since that would mean that none of his features would be developed end-to-end in a sprint. As their coach, while I was supportive of the Product Owner’s judgement, I was not sure whether I truly understood the team’s problem. I wanted to try an exercise of discovery with the group, and was concerned whether the group would allow for space and time to go with it.

So I christened ‘walk the dog’ technique. “Sounds like its time to walk the dog,” I said. ‘Sounds cool,’ said some one in the group, others looked perplexed, and afew others perked up.

So I asked the team to bring all their user stories from the current sprint. Starting with the first one, I asked them to walk me through the changes in code base that they will have to make in order to implement this story. I clarified that changes were considered only at the component level and not at the individual class file level. Then we picked another user story and did the same for that user story. At the end when we were done with all the user stories in the sprint, the picture looked like this.

We all stood back and after a few private moments of reflection, one of the teammembers asked why we are modifying on so many components in the same sprint? – bingo!

After this short diagraming exercise where the team literally walked each user story (the dog) through the changes in our components, the team was able to realize that the problem was not with the way user stories were split, but it was the lack of focus created by too many moving parts. The team was then able to rationalize why they were still trapped in their silos and why they were facing so many integration problems.

Earlier the team was asking the PO to split user stories along components so that they could manage complexity within their sprint. This exercise revealed another approach for the team. By limiting technical diversity for their in-sprint user stories, the team was able to reduce complexity within their sprint and also deliver vertical slices of valuable functionality for their product owner.

Scrum Exposes the Mess With No Quality Built In (Part 2 of 5)

  

 Email Article  

Tweet  

  

by Monica Yap

I had lunch with a group of Agile coaches recently in Shanghai (yes, they are doing Agile in Shanghai!), and one of the coaches mentioned that screw manufacturers now have a screw-building machine that automatically validates that the screw size and length is up to specification as each screw is cut. A screw is the smallest unit of any appliance or machinery, right? They are essentially building quality and validation into each unit. This is what we called ‘building quality in from the beginning’.

Now switch over to the software world — I speak to this as a developer myself for 20 years with extensive experience working with other developers. When we (developers) are in the traditional development cycle, we get used to the design-code-test phases, and because the test phase is at the end it’s also most likely to be performed by a different group of people (testers). Although we spot check our code from time to time, true testing is usually not top of mind until the end when we have to fix bugs. Furthermore, testing is not in our job spec. So we don’t really know if the code satisfies the functional, security, and performance requirements until the very end. This creates a problem if the true quality is not baked into the code from the beginning. Again, Scrum exposes this by requiring shippable code from each Sprint (which means it has to work functionally), and it makes the whole team accountable for the results, not just the testers. This means the quality has to be built into every Sprint. The most effective way to do this is to ensure each unit in the code works as it was designed to do.

So how do we design a screw machine that will measure each screw as it is produced? We first need to learn how to do automated unit testing, i.e. test each method or function which has interesting logic — we learn how to do Test Driven Development (TDD). TDD is not just unit testing; it’s a practice that will shift our way of designing our code into more loosely coupled and easily testable units. So now we have each unit and foundational block in our code that is tested and we’re confident. Next we need to start building automated Story tests each Sprint, so the code for the new features is tested as it is developed, and all existing features are regression tested during each Sprint. Testers are part of the Scrum team, and they can help writing story tests from the beginning as well. Next would be automated load/performance testing, so that the risk of ‘oh my god, we used a database that cannot perform’ will be discovered at the beginning, rather than at the end before the release.

Now let’s fast-forward to post launch, when the next version needs to be developed. New teams are formed or new team members are added to develop the new version — this is usually the case, isn’t it? They will be handed over the code and all the unit, functional, and performance tests will serve as ‘live’ documentation rather than a static Word doc that is usually out of date. They can then change or add new features safely, and perform more tests to enhance the code.

These practices are not small tasks, not to mention the learning curves for all roles in the team. ‘Who will be paying for this?’ is always the question being asked. My answer is that we all will be ultimately paying for the cost of not doing these practices, i.e. long bug fix cycle, rework, delay of launching, missing early release window opportunities, etc. My experience is that the cost of not doing these is far greater in the long run than the cost of doing them, especially if your product is to survive to the next version. [Also see ‘Does unit testing pay off?’]

TDD Cycle

How Should We Deal With the Mess That Scrum Exposes? (Part 1 of 5)

  

 Email Article  

Tweet  

  

by Monica Yap

I often tell people that Scrum is great, but that it exposes a lot of the mess which normally hides under long development cycles. The mess of integration, fragile and unstable code, quality not built in from the beginning, and specialized roles that cost overall efficiency on delivery. Let’s look at each of these and the technical practices from Extreme Programming (XP) can help address them. In each blog of this series, I will cover one mess.

The mess of integration

In a much longer development life cycle, we are talking about months or even years here, we wait to integrate until the end before release. This creates a huge integration risk, and it usually comes with big surprises that ultimately lead to a lot of rework that inevitably delays the release or certain already ‘built’ features to be cut. Also, the delay integration creates a much higher cost on fixing any defect. Scrum exposes this issue by delivering end-to-end potentially shippable features during every Sprint in the framework, so we are required to integrate the changes into to the overall product in each Sprint, and hence lower the cost of any defect found within a Sprint.

So now the question is – how do we do this? Doing manual integration (which we used to do) is just way too painful for every Sprint, so some teams revert to having ‘hardening’ Sprint(s) before releases, where the integration happens. This is still a big risk and surprises will definitely arise, so now we are back to the question of how can we integrate every Sprint in a sustainable way? One of the Extreme Programming practices, Continuous Integration, is the key practice to help us get to sustainable integration pace. As small changes are checked into the common source code repository, along with tests (more on this later), we have an automated engine to perform a build, run all the tests, and spit out the errors when it fails — then whoever checks in has to fix the errors and rebuild, while no one else is allowed to check in until the build is fixed. (Note that this is not just a technology or magical server, it’s a practice carried out rigorously by all team members and all teams.) So in time, we will have a code base that is always integrated and tested.

In the next blog I will talk about the mess with no quality built in.

Product Owner Anti-Patterns, Part 3: No Single Product Owner

  

 Email Article  

Tweet  

  

by Monica Yap

In my earlier blog posts in this series, I shared with you the Absent Product Owner, and the Churning Backlog pattern. The next anti-pattern I would like to explore is No Single Product Owner.

What does No Single Product Owner mean?

This phenomenon occurs when the business organization does not allow or support single decision-makers as the Product Owner. Sometimes the subject matter experts or stakeholders start acting as product owners. This causes the team to thrash on the different decisions made or directions given by multiple product owners. The team will waste a lot of time and energy to decipher whose decision is correct, and eventually a team member will “act” as the PO and make final decisions, which may or may not align with the product vision, roadmap, or release plan. The person who eventually makes the final decision may incur excess cost to the final product by either specifying excess and/or incorrect functionality. In the worst case, these decisions may cumulatively change the overall product direction.

Common Root Causes:

• The product is too complex or too large for one Product Owner to direct multiple teams and work with multiple product areas.
• The organization believes the Product Owner is merely a part-time role, and multiple people can “fill in” as needed.

Smells:

• During initial release planning, no single person can be identified as PO and determine the release date or scope.
• Conflicting decisions are made by different stakeholders or domain experts.
• Multiple stakeholders or domain experts attend Sprint planning and each one is “in charge” of one or more product areas.
• Team members spend a lot of effort to get final answers from multiple people.
• The project sponsor is a committee and some of the above smells occur.

Remedies:

Try the following for complex and large products:

1. Divide the product into multiple product areas, each with its own backlog and Product Owner. If there is enough work to be done in each area, different product owners can own separate product areas.
2. Have each PO will work with the team(s) on a full-time basis.
3. Propose one person as the chief Product Owner, who in turn owns the overall ROI, and product releases.
4. Create regular Meta Scrum meetings to coordinate between the POs and Chief PO.

Try the following for the PO as a part time role:

1. Measure and summarize the amount of time and rework each team member when there is ubiquitous direction or decisions made by multiple POs. In the case of one team member act as PO proxy, also add in this time spent on preparing the backlog and clarifying questions for a user story.
2. Present this objective data to the senior management and compare the cost effect of having a single PO vs. multiple POs.
3. Propose moving to a single PO to set product direction, supported by the stakeholders/domain experts as his/her product definition team.

If none of the above options is satisfied, raise this as impediment to the organizational level.

Product Owner Anti-Patterns, Part 2: The Churning Backlog

  

 Email Article  

Tweet  

  

by Monica Yap

In my first post in this series, I described a Product Owner anti-pattern known as the Absent Product Owner. Now I’d like to introduce you to another: the Churning Backlog.

What is a Churning Backlog?

During a sprint, the sprint backlog (which is supposed to be locked down) is consistently being changed at the request of the Product Owner — either stories are being added or existing stories are being modified to the extent that the team needs to re-plan and a large amount of re-tasking must take place. This can be caused by any of the common root causes listed below. When this happens, the team cannot stay focused because what they are working on keeps changing, a lot of waste is produced (unfinished code is waste), and the team will not be productive.

Common Root Causes:

• There is not enough planning done at a higher level, i.e. no Release Plan or Product Roadmap.
• There is no adequate pre-planning done in between sprints; this is also called backlog grooming or a look-ahead.
• There is no adequate planning done with the appropriate stakeholders, so there are ‘surprise’ requests coming from the unexpected stakeholders. This also ties in with another anti-pattern called Not Enough Stakeholders, which I’ll cover in a future post.
• The Product Owner is not fully aligned with the product release, vision, or strategy, therefore the backlog must be adjusted.

Smells:

• The sprint backlog is always changing during the iteration. This can be detected through analyzing the sprint burndown charts.
• The Product Owner and stakeholders rationalize small changes. “This is just a clarification, it shouldn’t impact the sprint.” “This is the same size as X, so pull X out and do this instead.”
• The Product Owner and team continually have to split stories to get something done during the sprint.

Remedies:

• Pre-planning with the Product Owner before each sprint planning session, and identifying concrete acceptance criteria for each story. The ScrumMaster should be able to help to ensure that this happens.

Personal experience: When I was a ScrumMaster, I set up reoccurring meetings with my Product Owner to groom the backlog a week before sprint planning — this helped to identify questions (or gaps) the PO would need to clarify to get answers. Then I scheduled another follow-up meeting with the PO and the team to preview the stories at the top of the backlog to get a high-level estimate and draw out more questions that needed to be addressed during sprint planning.

• Help the Product Owner to establish a group of stakeholders as the Product Definition Team, and set up a backlog brainstorming and prioritization session regularly (the interval depends on the product and context).

Personal experience: A Product Owner I worked with had stakeholders scattered in different cities. He flew them into the home office every quarter, and they worked together to conduct release planning, roadmap updates, backlog brainstorming, story writing, and prioritization. This allowed those stakeholders to provide their input and enabled the PO to understand their priorities — the group worked together to calibrate their priorities, so all stakeholders had buy-in and supported the release plan.

• Help the Product Owner and business community commit to a vision statement, a roadmap, then a release plan

Are We Going to Make It?

  

 Email Article  

Tweet  

  

by Thomas Vollmer

In my previous post, I wrote about the importance of trust for effective agile development. A good way to build trust is to say what you are going to do, and then doing it.

For any given sprint, the team says what they are going to do in three major ways: definition of done, working agreement, and sprint commitment:

• The definition of done shows what actions the team considers mandatory for an item to be done. Often, different criteria are used for tasks, stories, sprints, and releases. For example, one criterion for a task to be done may be that the code is checked in and all tests pass.
• The working agreement shows how the team has decided to work together. For example, the team may require that all production code be written in pairs.
• The sprint commitment is given by the team during sprint planning, and includes which stories the team believes it can deliver that sprint.

Note that the definition of done and the working agreement are overall team agreements and not sprint specific. Also, they are very specific to any given team, and are best determined and agreed upon by that team for their particular situation.

Throughout the sprint, it is up to the team to do what they said they were going to do. Three things you can do at each daily standup to achieve this are:

1. As a team, take a quick look at the burndown chart
2. As a team, ask “are we going to make it?”
3. If not, discuss as a team what can be done in order to make it

What exact actions the team decides to take when things aren’t going well is of course critical. Helping each other out even though it’s “not my job” and doing the simplest thing possible (but no simpler) to solve technical problems are great. If that doesn’t suffice, I recommend thinking about not finishing one of the stories, which will directly reflect in velocity. This is by far the simplest to manage because the effect is immediate and highly visible. Breaking the definition of done or the working agreement (which usually translates to a drop in quality) usually causes indirect, non-linear and unpredictable effects.

Phase-B-Gone

  

 Email Article  

Tweet  

  

by Thomas Vollmer

Are you deploying to production every sprint? If you are, congratulations! If you are not, you’ll likely have some unpredictability around your release date, your release scope, your level of quality, the work/life-balance of everyone involved, or any combination thereof. How much unpredictability depends on the definition of done for your sprints.

A weaker definition of done causes a larger amount of release debt to accumulate. This debt must be paid off to some degree before you can deploy to production. The time it takes to pay down the debt represents a development phase in the traditional sense, no matter what you call it (“stabilization sprint”, I’m looking at you).

A strong definition of done helps keep release debt to a minimum. As such, the definition of done’s primary function is to reduce or even completely eliminate development phases that delay deploying to production so you can start earning a return on your investment earlier.

Delivering Value with Agile: Cleaning Up the Code

  

 Email Article  

Tweet  

  

by Dan Williams

I am a ScrumMaster assigned to a software development team at a client site. Usually the team is working on assigned development projects using a standard Agile/Scrum method. Sprints are 2 weeks in length with a demo of completed user stories at the end of each sprint.

Currently the team has been given a project which is in its Initiation phase. It is the decommissioning of a major application suite of over 100 identified functional features. There is a business case in place but no funding as yet. The team was tasked with doing research to identify functional business owners, number of users for each function, number of accesses per day, etc., with a view toward recommending sunsetting underused functionality or migrating functionality to current technology platforms.

Having completed this upfront work, and preparing to engage the business, the team identified the need to better understand the legacy code in preparation to either sunsetting or migrating functionality to other platforms. To that end, the team decided to investigate and then address ignored unit and functional tests in the code base. In this way they could deliver value to the IT product owner by cleaning up the code and ensuring everything was working properly prior to the decision to sunset or migrate.

The analysis showed over 122 ignored tests. The team chose to timebox the effort to a one week sprint. The number of identified ignored tests formed the vertical axis which often used for either story points or task hours on a burndown chart. As with tasks, the number of hours remaining after each day is decremented from the total showing a downward slope unless more tasks or task hours are identified.

At the end of the sprint, we will show the product owner how many we have fixed and how many remain, thus delivering measurable value to the IT product owner. This is yet another way to deliver value using Agile.