Measure Outcomes - A New Process Goal
| We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goals: Intake Work, Organize Metrics, and Measure Outcomes. The focus of this posting is the Measure Outcomes process goal, the goal diagram for which is posted in Figure 1.
Figure 1. The Measure Outcomes process goal diagram (click to enlarge).
The Measure Outcomes process goal describes potential improvement outcomes, or improvement goals, and suggests potential metrics to measure progress against those outcomes. Disciplined Agile doesn't prescribe what to measure, that would be naive because every team is unique with its own priorities and desired outcomes. All of the potential outcomes in Figure 1 are important. However, you will want to focus on a subset at any given time, and that subset is likely to evolve as your improvement focus evolves. Context counts.
Related Resources
|
Organize Metrics - A New Process Goal
| We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goals: Intake Work, Organize Metrics, and Measure Outcomes. The focus of this posting is the Organize Metrics process goal, depicted in Figure 1.
Figure 1. The Organize Metrics process goal diagram (click to enlarge).
As the name implies, this process goal describes strategies to organize the metrics approach within your team. This strategy will be driven both by your team's culture and skills as well as the needs of your stakeholders - your metrics will likely need to "roll up" to the program or portfolio level. Your metrics strategy will focus on several important questions:
Where this goal focuses on how to measure, the Measure Outcomes goal describes what to potentially measure.
Related Resources
|
Intake Work - A New Process Goal
| We recently released the 5.2 version of the Disciplined Agile (DA) tool kit, and in that release we added three new process goals: Intake Work, Organize Metrics, and Measure Outcomes. The focus of this posting is the Intake Work process goal. Intake Work: AddedFigure 1 depicts the process goal diagram for Intake Work (see How to Read Process Goal Diagrams). This is how a team pulls in work from their "upstream" stakeholders. The incoming work is examined and if ready it is prioritized and put on the team's work backlog. We introduced this process goal because we wanted to have a cohesive source of process information capturing the issues around a common activity that is critical to your team's success. Figure 1. The Intake Work process goal diagram (click to enlarge)
To be effective at intaking work, we need to consider several important questions:
Address Changing Stakeholder Needs: RefactoredPart of the development of Intake Work was the refactoring of Address Changing Stakeholder Needs which previously captured several decision points that focused on intaking work and several on exploring stakeholder needs. Figure 2 depicts the updated goal diagram. Important changes include:
Figure 2. The Address Changing Stakeholder Needs goal diagram (click to enlarge)
Related Resources
|
A retrospective on years of process tailoring workshops
In my experience in running dozens of process tailoring workshops, over several years, with of teams of every shape size and experience level and in different organizations, the most recurring comment is that the workshops “revealed all kinds of options we didn’t even realize were options!” Although almost always a bit of a hard sell at the outset, I have yet to work with a team unable to quickly grasp and appreciate the value of these activities. I had to do quite a bit of experimenting in order to get the timing and content of the workshops right – and learned over time that success is also predicated on knowing whom to include when. My first attempts were gruelling, close-to-full day affairs with entire teams in attendance, held at or close to project kickoff. Though transparent and inclusive, to my surprise this approach was actually deemed a waste of their time by many team members, especially those whose contribution would occur primarily in the construction phase. First lesson learned – A technical team lead, architect or senior developer can actually stand in for most of the developers in the early stages. I find it helpful to always bear in mind what George Dinwiddie (http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/) dubbed “the 3 amigos” in determining who needs to attend a process tailoring session. Be it at inception, construction, or even in transition, you need to tailor not only the processes, but also the attendance of the workshop in order to ensure you have the right mix of people, with the right collaborative mindset, to cover issues pertaining to 1) the business problem being addressed 2) the potential technical solutions to that business problem and 3) the processes (both team and organizational) that will enable the work to be carried out. My second lesson learned pertained to the format and presentation of the process blades themselves. I found that simply working from the published process maps was insufficient, as we ran into onerous issues around how to best record the WoW choices teams were making. I eventually reproduced the entire process blade library in a spreadsheet format, with columns for comments. This seemingly innocuous administrative step quickly ushered in the third lesson learned – the sessions can be used not merely to document an immediate WoW decision, but also to identify future, more “mature” aspirational choices which the team can set as goals over a specified time period. A fourth lesson learned, and one that was also enabled by using a simple spreadsheet tool, is that it became far easier to Align with Enterprise Direction. By “locking down” enterprise-level process choices across all the blades where applicable, a lot of potentially fruitless (at that point in time) discussion was saved for many a team. No use in discussing test automation strategies to death for instance in divisions still completely relying on manual tests, or at the opposite end of the spectrum, teams endowed with high-performing, well-integrated CI/CD environments. This is a large part of what DA calls self-organization within appropriate governance. The fifth and final major lesson learned was to never start from a blank slate if at all possible. I would typically show up at a team’s first process tailoring workshop with a pre-filled version from another team facing somewhat similar challenges (the identifying data being scrubbed so they could not identify the previous team). I would then challenge the new team to reflect on the choices and determine whether they made sense for their own context. This also saved time and effort, as there are recurring themes and common challenges within organizations that all teams face. Here’s an important note on determining participation – Ultimately, the teams themselves are the best arbiters of who should attend the sessions at varying stages of advancement. Allowing this will typically result in a bit of initial over participation, followed by under participation (especially is the pressure is on to get “real” work done!) – the key as facilitator is to coax the team back into balanced participation, and to lobby the organization for the necessary support in freeing people up. The support will become easier and easier to obtain as the benefits of allowing teams to choose their WoW become apparent. Finally, be prepared for surprises. I once ran through the Program process blade with a team, only to have them come to the realization that … they weren’t really a Program! Which was actually a good thing as it helped avoid introducing a considerable amount of overhead, particularly in the area of program-level KPIs. |
Disciplined Agile Release Management: A Goal-Driven Approach
| This posting, the latest in a series focused on a disciplined agile approach to release management, overviews the activities associated with release management. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy. The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog we present the goal diagram for the Release Management process blade and overview its process factors. The following process goal diagram overviews the potential activities associated with disciplined agile release management.
The process factors that you need to consider for release management are:
Release Management and DevOpsRelease management is an important part of your Disciplined DevOps strategy. Having said that, many IT departments are still in their early days of adopting a DevOps approach yet still effective release management. The implication is that the way that you approach release management will vary depending on how far down the DevOps adoption path you are. For example, with no DevOps in place at all your release management activities are likely to be performed by a team that is completely separate from your IT delivery teams. When you are in the process of adopting a DevOps mindset release management is likely to be a collaborative effort between the IT delivery teams and the release management team. When you have fully adopted DevOps strategies release management is mostly performed by the delivery teams themselves.
Related Postings |
.jpg)
