We Need a Shared Understanding
Last Updated on Friday, 27 September 2013 11:12 Written by Derek Huether Friday, 27 September 2013 11:12
Earlier this week, I facilitated a backlog refinement meeting. In the past, the team was used to the analysts to complete all of the requirements in advance. The delivery team would then execute on those requirements. The problem, of course, was no shared understanding.
We came into the meeting with everyone agreeing they were on the same page. That was true for about 15 minutes. The more we talked, the more they realized they were looking at things from individual perspectives.
At the beginning of the meeting, we had less than 10 user stories, from an analyst’s perspective. By the end of the meeting, we had a prioritized backlog with over 100 user stories at different levels of granularity. They understand that it’s not perfect. But, it’s a start. For the first time, developers and testers were engaged at the beginning of the process. At LeadingAgile, we call this the Product Owner team. When the highest priority stories get to a “ready” state, they will be pulled into a delivery team’s queue. Until then, we need to answer some of the more complicated questions, mitigate risk, and achieve that shared understanding.
Image Source: Based on a hand drawn image from PictofigoLearn More
Agile Release Planning Kick-Starts Agile Adoption and Yields Quick Wins
Last Updated on Monday, 1 July 2013 01:07 Written by Doug Brophy Wednesday, 3 July 2013 07:00
Organizations just starting out in their adoption of Agile software development are eager to begin seeing results. After proper Agile teams have been formed and trained in the basics of Agile, they are ready to begin practicing. But what is the first step, where should they start? Agile Release Planning is the answer.
Agile Release Planning enables teams to get started “doing Agile” quickly. It brings the stakeholders together in a working session focused on developing the software requirements and plans to develop the software incrementally and iteratively. Risks, issues, dependencies and assumptions are identified and addressed in the planning.
This kick-starts the adoption of Agile practices, enables teams to begin delivering results quickly, and sets them up for success with the release. A recent coaching engagement provided a good example of this.
An Agile development team had been formed to build the next generation platform for a Resource and Operational Planning tool suite. A new platform with a single, common database and user interface was needed to better integrate and present the product offerings, in line with the product vision and roadmap. The legacy platform had become overly burdened with technical debt after years of ad hoc development, and became costly to support and extend.
The new team was in its forming stage. There were conflicting views and differences in understanding of the requirements for the next generation platform. There were strong differences of opinion about what and how to leverage from the existing platform architecture and code base, which was large and complex.
Most of the new team came from the legacy platform development team. But the Product Owner (PO) and Product Manager (PM), two developers and a tester were from a different but similar product suite. The PO had recently been part of a similar platform uplift program for the other product suite, and had a developer background. As such, the PO had strong opinions about how to execute this project, including on the subject of architecture and code reuse. He strongly advocated for starting over with a new clean architecture since, for example, the existing platform had lots of business logic tightly coupled with the UI.
But the legacy development team members were very concerned about doing this. They were counting on re-using a lot of the legacy code (and architecture). In their minds, that would be the fastest way to complete the project, since they were very experienced in development of the legacy platform.
To overcome these issues, we held a Release Planning Workshop. Representatives from Product Management, Development, and other stakeholders in the release were in attendance. Our workshop began with an intentional focus on reviewing the business goals and associated product vision and roadmap, as a precursor to talking about architecture, epics, features, and stories. This quickly made it clear to Product Management that they were not fully prepared to discuss the platform requirements in this manner.
We were able to identify some epics/ features and stories on that first day of the workshop, but it was mostly a training exercise for the team to learn what and how we do release planning. With this new understanding, Product Management asked for a week to go “do their homework” to fully prepare for another try at Agile release planning.
We reconvened a week later for “take two” of release planning. This time we made rapid progress and accomplished the goals of release planning. Notable outcomes include the following.
1) Development finally understood and accepted that Product Management wanted a new, simplified, de-coupled architecture – not just a refactoring of the existing architecture. This would be the basis for a normalization of how data entry, processing, and presentation would be done across products/ features running on the new, common platform.
2) Delivery date would be negotiable as the project progressed. Development had been assuming that there would be a fixed due date 9-12 months later, which they would be pressured to accept, even though it would be high risk to commit to a delivery date that far out. But Product Management did not have a fixed due date in mind. Instead, getting the new platform they envisioned was the priority for them. They could be flexible about the final completion date.
3) Product Management did want to see incremental milestones of progress, and fortunately, that is exactly what Agile release planning is designed to provide. The plan was for Development to deliver a release every quarter, internally only, incrementally and iteratively building up the platform with every internal release, leading up to the final product release.
4) With a well-groomed release backlog coming out of the gate, the team could begin planning and executing sprints, and gauging their velocity. This in turn would enable refining of the release plan as the project progressed.
5) The team delivered a demo by the end of the second sprint, and every sprint thereafter. They recently made their first quarterly release milestone.
For a new development team with only basic Agile training prior to release planning, within two weeks we had a mutually agreed upon viable release plan that enabled the team to begin executing sprints aligned to the first quarterly release. They had learned how to capture product requirements as user/ role and goal –centric epics, features and stories, create acceptance criteria, estimate stories in relative story points, and they were ready for the first sprint planning and execution.
Without good Agile release planning, teams often try to start sprinting with a poorly groomed backlog, with no clear direction towards delivering on release goals. This can result in wasted time and effort (money), engraining of bad habits, as well as frustration and disappointment with Agile.Learn More
Visual Evidence of an Agile Release
Last Updated on Wednesday, 12 June 2013 02:54 Written by Peter Callies Wednesday, 12 June 2013 02:54
Below is a fancy release burnup chart (click it to see the full image) that visually shows the work of a team from a recent release by a LeadingAgile client.
The red line effectively is the amount of risk. You can see that the team started the release with about 50% of their stories unsized, but consistently drove that down through the first half of the release.
You can see the impact of end-of-release hardening in the flatness of the shaded blue area on the right side of the chart.
In the shaded gray area, you can see the team performing backlog grooming, breaking down the work into estimated stories and even cutting scope mid-release (the gray area increases as the red line decreases).
The flatness of the shaded blue area early in the release shows the impact of a backlog that isn’t well-groomed, but as the team drove that red line down, the blue area takes on a more-consistent positive slope.
Cool stuff that demonstrates the impact of a groomed backlog and the effectiveness of a team.
Replacing the Iron Triangle of Project Management?
Last Updated on Thursday, 15 November 2012 01:04 Written by Mike Cottmeyer Thursday, 28 January 2010 03:36
Last year sometime, I heard Jim Highsmith do a talk on replacing the traditional project management iron triangle with a new ‘agile triangle’ that is based not on time, cost, and scope… but instead, based on value, quality, and constraints (time, cost, and scope). This is a concept Jim introduced in the latest release of his book Agile Project Management: Creating Innovative Products. Something in the idea has been bugging me a little, so when I read Isreal Gat’s post this morning, discussing ways to use Jim’s agile triangle, it got me thinking.
I’m curious if the agile triangle follows this same pattern. If I increase value, does quality have to go up or down? Do the constraints have to change? What about if I change quality? Does value go up? Do I have to change the constraints? What about the constraints? If I tweak the constraints, does that always impact value or quality? There are some guesses that we can make, but the agile triangle doesn’t give us any guidance. The relationships between the variables are less precise, and therefore I think using the triangle metaphor is less powerful.
My Life is a Project?
Last Updated on Thursday, 15 November 2012 01:04 Written by Mike Cottmeyer Wednesday, 23 December 2009 04:23
When I’m giving talks or teaching a class, I often talk about how I think about nearly everything in my life as a project. So much so that my wife sometimes complains that she is not a project that I have to manage! She get’s tired of talking about risk mitigation strategies and desired outcomes. She isn’t particularly interested in understanding our assumptions or constraints and really does not like being called a primary stakeholder.
In all seriousness… I don’t quite take it that far… but I do tend to see things through a ‘project’ lens.
Earlier this morning I came across a great post by Scott Berkund titled ‘Everything is a Project‘. I liked the post so much (for obvious reasons) that I sent it out as an ‘Interesting Post…’ over Twitter. Several folks re-tweeted my tweet and a few folks commented. One of the comments came from Bob Marshall, aka @flowchainsensei. Here is what Bob had to say:
@flowchainsensei Way too many things are projects – especially projects. Projects are dysfunctional, wasteful and anti-flow. Let’s put an end!
And my response…
@ mcottmeyer I think that the project metaphor can be useful when we don’t have level investment across product lines.
Clearly this was way too deep a topic to explain in 140 characters, so I wanted to share my thoughts around projects and where I think they are useful… and where I think the concept is overused.
First… the simple definition of a project goes something like this… ‘a project is a temporary endeavor, with a defined beginning and end, that is created to achieve some particular goal or desired outcome’. I’m pretty sure that definition came from the PMBOK, but I lifted the language from Wikipedia. Pretty basic and seems to make sense, but does it fit the way that our organization really does work?
Here is another example where I think projects are misused. If I am a small company that is developing a single product, and my primary mission in life is to keep that product updated with new features and defect free… is the work I am doing project work? I may be inclined to have a “UI redesign project” or a “Revise the login and authentication project”. Are either of these projects? They could be, but because of the nature of my environment, what we are really doing is ongoing product development.
But… what if I am building a custom solution that will be handed over to the customer at the end of the contract period. I may provide ongoing support, I may not. In that kind of environment, it might make sense to have a project manager and a charter… a formal risk mitigation plan and at least a high level schedule… even in an agile environment. I have touch points with my primary stakeholders (no, not my wife) and they have certain expectations about how their money is going to be spent. This sounds like it could be a good place to have a project.
Let’s consider another example… What if my product company grows up and now we are supporting 20 different products and have 40 to 50 teams. Your product sets are not all the same level of maturity. Some are established and don’t need incremental investment.. some are less mature and require new features to be added to meet market demand. The point here is that the investment in each product is not level and the business is making strategic decisions about where it will spend its money to get the greatest return. I think that projects make sense here too. We are making an increment of investment, over a pre-defined period of time, to get some desirable outcome.
So… do I think that projects are overused? Yes. Am I willing to say that all projects are bad and that the entire metaphor is outdated and always inappropriate? No. Like most everything we talk about here… you have to understand your context and not apply concepts blindly where they don’t make sense. If your work is more operational and ongoing… that is not the sweet spot for project management. If your work is well defined and discrete, and it lends itself to the problem that project management is designed to address… I think the concept is valuable.
It is not a one size fits all world. I look forward to the conversation.