Agile MVP Model, cont.

The Agile MVP model serves as a template for the kind of Agile coaching and training work that I’ve most enjoyed doing. Most recently, I’ve been able to use it to deliver agile transformations successfully in an Agile way. In other words, create sustainable Agile cultural change by having people experience the journey in the most holistic Agile manner.

These are the five steps I use. As I mentioned before, the key to this model is that the steps happen in a time-boxed period and result in a visual deliverable that drives the cycle.

1. Work Ideation — identify the nature of the work activity or process. What is our goal? What is value? Where do we want to be?

Sometimes clients have strategic plans or priorities or other artifacts that we can use. Or, I schedule a 2- hour workshop to visually capture the results. The outputs could be Lean Canvas, A3 template, or any kind of roadmap.

2. Work Intake

The work intake process captures the reality and the context of a given environment — all the unplanned, ad-hoc work as well as management and other operational activities.

Serves as a “reality check” to the vision represented in the Ideation step. Enables decisions to be made on actual data, not just planned work.

I’ve done this process in a variety of ways, but the most successful has been something we call the Agile Kaleidoscope. I adopted this technique from my partner-in-crime at the US Courts, Roland Cuellar, and it became one of my favorites instantly.

3. Work Sequencing — another time boxed workshop to create either a process or activity map that answers the following questions:

• What does done mean? In other words, do we know what the output would be? Who makes the decision? Proof of concept or final, polished output?
• How do we approach our work? How do we make decisions on what to do next?
• Do we have a plan for how we do things? Standardized work, for example

Basically, determine how to chunk the work to obtain early and frequent value delivery.  Identify definition of done for overall deliverable as well as incremental deliveries, so that high-value, high-risk work items can be done first.

Value Stream Mapping is one useful visualization process/output to help with work sequencing; but remember to tailor the level of effort to the value provided by the process.

4. Work Delivery — this is where most current Agile efforts happen. The goal is to get end product done and verified (tested) in small batches within time-boxed periods.

Use visual representation of work to monitor progress and issues, most often a Kanban board or task board to represent current work and its status serves the purpose.

5. Work Validation

Finally, the inspect and adapt step that is standard in all Agile frameworks. Use frequent demonstrations and retrospectives to improve transparency and to drive continuous improvement. Should validate that what we’re delivering is value to our customer as verify that our process is effective. Again, capture the result of each work validation cycle in a visual format that feeds back into the ideation step.

 

 

Agile MVP Model

The Agile MVP model is a light-weight framework that is designed to apply the essence of Lean-Agile principles to deliver value for any type of work activity or process.

This model is a distillation of work I’ve done over the years, though I’ve only recently combined and refined the components into a cohesive whole.

The basic question this model answers: what would be the ideal way for me to do my work, if I could do it in the most Agile way. The what and how really boils down to maximizing the percentage of value-added work on my work and minimizing the level of resource commitment/cost on the client’s behalf.

As you will note, there is no mention of project in this model or of information technology. And that is quite deliberate.

One of my pet peeves as an Agile coach is the myth that Agile is an “alternate project management method”. This myth is often reinforced in the federal space, since most Agile coaching contracts are embedded within the project management division or aligned with a specific software development project.

And even though the Agile manifesto specifically refers to software development, there is nothing in the core Agile values that is specific to information technology.

So I’ve always operated from the conviction that just because Agile’s most visible successes have been within the domain of software development projects, that doesn’t mean that Agile is limited to those domains. After all, Agile to me is “early and frequent delivery of incremental business value”. And that concept can be applied to any activity or process, even thinking!

This model can be used to streamline process such as logistics, operations, quality, sales and customer service, procurement and inventory management and finance that are staples in virtually any industry. Even more valuable is that this model can enable these entities to be strategic partners in their enterprise’s success instead of just being support services or overhead.

I’ve used variations of this model for years, initially prototyping elements of it in my personal life, with my teams when I was a ScrumMaster, with non-profits where I volunteered as a way to assist with strategic planning, etc. And more recently, I was able to deliver the model within the government sector, with some positive results.

The model consists of five steps – ideation, intake, sequencing, delivery, validation. It is possible to start anywhere in the cycle, but for maximum value, the steps should be done in this sequence. The Minimal Viable Product (MVP) part of this model is that four of the five steps can be done in with minimal time and resource commitments.

Most often, customers resist setting aside to “create” new process as they’re swamped with existing work. Recognizing this reality and other constraints, I have been able to complete each step in as little as four hours; work delivery being the obvious exception since that is time-boxed for 1-4 weeks. A single half-day workshop for each step results in a visual output that can drive the next step. There are no other documents or deliverables required; these five visual outputs (usually about a page or two each), are enough to drive the transformation or improvement effort.

Obviously the model can be scaled with more time and resources as the need and value necessitate. There are occasions where I’ve asked clients to do “homework” – preparatory work to get the most value from the workshops, since they do represent a significant resource cost for the client – the time of their people, the opportunity cost of not doing other “work” as well as the cost of my efforts.

I’ll detail the model in the next post, but the five steps are ideation, intake, sequencing,  delivery and validation.

Measuring Value, 4

Revisiting the process of developing metrics that can provide a way to measure the degree of Agility by focusing on the 12 Agile principles, we’re now at principle #4:

Business people and developers must work together daily throughout the project.

This is among the fewest words in a principle, but the one I think is most open-ended.

When these principles were developed, Agile was intended for software development projects. And while software development remains the most common application of Agile, its reach has gone way beyond – not just to the tangentially related areas such as software maintenance but I’ve seen teams applying the Agile methodology to efforts such as marketing, content generation, a wide range of strategic efforts, help desk management and event planning!

So in this context, who are the “business people”? And what if you don’t have developers since you’re not delivering software?

The key element — partnership between the creators and the consumers — however defined for each effort, is still the core value. The intent is to enable and use short feedback loops where the creators are validating their assumptions with the potential consumers and other stakeholders.

Since the value being measured basically boils down to environments where trust and collaboration are actively prioritized, not just stated, the outcome-based metrics that can capture this rather qualitative concept are a bit more challenging.

The primary metric would be a measure of organizational trust / transparency. This could be measured via an employee satisfaction survey or scorecard. The questions on the survey, which should allow for a range of answers, could address topics such as:

• Do you feel that your team is self-organized?
• Do you feel that you and/or your team are empowered to make decisions about your work?
• How comfortable are you and/or your team in discussing bad news or failure with leadership?
• What percentage of your time [daily or weekly] is value-added?
• How often have addressed a co-worker directly to raise an issue or potential problem?

There are entire books and disciplines addressing the craft of developing open-ended, non-leading questions so writing the questionnaire should be done by a specialist.

In addition, the following quantitative measures could be provided by agile teams:

• % of sprints where team has at least one activity focused on improving team culture, for example: team building, team lunch, shared activity such as March Madness pool
• % of sprints where teams look at happiness as part of the retrospective process and takes actions based on it
• Percentage of nontechnical Impediments in each team’s impediment list (indicates that team members are aware of cultural and communication blockers)

By combining these quantitative and qualitative metrics in a way that is best suited to each effort or organization, hopefully we can provide some insight into the degree of trust and collaboration prevalent in the environment and where we need to improve.

Measuring Value, 3

As part of the ongoing look at metrics that can help indicate whether a project or team is being truly Agile, we’re going back to the basics – to the Agile principles.

#3 Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.

So, principle #3 is obviously the most fundamental, because if you’re not delivering working software (or other equivalent), then you’re probably not delivering value to the customer.

This is pretty much what I call an eyeball-level assessment, because it is so straightforward, but here are some of the metrics that could be used to capture the level of delivery value:

• % of stories that are releasable, i.e. stories that meet the definition of done

I definitely distinguish between releasable and released since less than 5% of teams I’ve worked with were set up to actually deliver to production/client at the end of every sprint. So whatever definition of done is for a specific team, that is what matters for this metric.

• % of releases where business value delivered and cadence are reviewed.
• Release value analysis (combination of planned vs. achieved and burn-down)

If you’re doing release-level planning and retrospectives, then you’re probably meeting the first criteria. The second is usually a custom measurement that combines several indicators to highlight client-specific priorities.

• % of completed epics / business features where team reviews the time it took to get across the board (cycle time)
• % of completed stories where teams review the time it took to get across the story board (story cycle time)

The first criteria is one I track for my own purposes especially for stable/mature teams because it can often reveal underlying pain points and that make for great discussion during retrospectives. The second applies when I present the data and then the team discusses trends, their implications as well as possible causes and effects.

• Distributions of all the story sizes in backlog go from smallest size/most stories to largest size/least stories.

I don’t track this as formal metric but it provides a good visual gauge for me to ensure that the backlog grooming is going well. If the size/quantity ratio is off, then I’m going to dig a little deeper into the backlog to see if there are any issues that need to be addressed.

As always, these metrics have been borrowed/adapted from several Agilists that I’ve met and worked with over the years, so thanks – and remember that all mistakes are my own!

For reference, the first two parts of this series are here and here

And remember that even the best metrics are a starting point for discussions because the context is just as important to understand the full picture.

Secret Life of an Agile BA

At the AgileDC conference yesterday, I had the opportunity to participate in a session called “Agile Paradoxes: Extensions or Contradictions?” by Awais Sheikh.

Awais’ thought-provoking presentation and the ensuing discussion made me think about a concept that evokes the same kind of back-and-forth dialogue:

(Agile) Business Analyst

Is the very concept of a BA a contradiction to Agile? Or is it an acknowledgement of the complexities of real-world, large-scale Agile projects?

In an ideal cross-functional, empowered team with wholly dedicated resources including a product owner, then the responsibilities of the BA role can be shared amongst the other team members and the goal is still being met.

But several of my projects haven’t quite resembled that best-case scenario.

I been a ScrumMaster for teams where business analysts (responsible for writing user stories and maintaining the backlog) were embedded in every team, along with a tester, a DBA and several developers.

I’ve experienced other teams where business analysts, usually based in a different department other than IT where the rest of the team was based, were sent through a few days training to become product owners and were responsible for creating and managing the backlog. As product owners, they spent a few hours daily in the team rooms, and the remaining at their desk in their respective business unit.

And then there are teams where the product owners, usually the clients, are responsible for prioritization and acceptance but do not actively maintain the backlog and develop user stories. They are often not co-located with the rest of the agile team but work with the teams while also doing their regular job. Instead business analysts act as proxy product owners and are responsible for gathering the “requirements” from the clients. They are sometimes part of the development teams, and in others, they are part of the “extended team” supporting one or more team.

I think any and all of these scenarios can work, but the devil is in the details as the saying goes.

The key element is that the level of delegation should match the level of responsibility. In other words, whoever is serving in the role of product owner (proxy or now) should be empowered to make the decisions on daily basis so that the scrum team can move forward confidently. The product owner can escalate as needed or to set priorities at the feature level.

Fundamentally, remember that the goal — a groomed, prioritized backlog where business value is ingrained — is what matters, not the role!

So now matter what your role is, if you own the backlog to any degree, then know that your work is the difference maker in the highest risk of an Agile project.

Measuring Value, 2

This post is a continuation of my efforts to identify metrics that could possibly reveal or capture if and to what degree an organization is delivering value in terms of each of the 12 agile principles.

So here’s principle #2:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The potential metrics for this principle got the most discussion – and disagreement – when I did this exercise with a group. The general takeaway was that the metrics you prioritize really depends on the maturity of the teams and organizations you’re exposed to.

When I worked with teams that were on the learning curve, about 80% of my efforts were in managing the sprint backlog, with the remaining on the release backlog. Most of our issues could be traced to requirements that were being included in sprint backlog even though weren’t fully articulated.

So I’ve used the following to track our effectiveness in addressing that issue. First, ensure that there is a clearly defined and agreed-upon process for adding scope to the sprint backlog. Then ensure that the process is strictly followed:

• % of the sprint backlog that is ready for the teams to start developing
• % of urgent mid-sprint requests that the team reviews and understands the impact on sprint delivery before accepting into the sprint, including the impact on velocity and burn-up charts
• Backlog flux – # of stories and total story points in the backlog at the start and end of each sprint

In instances where the teams and organizations are more mature in their agility, the following metrics could be revealing:

• % of stories that are reviewed and estimated by the team within one sprint of being placed into the backlog – indicates active grooming of the backlog
• Teams have multi-sprint burnup chart that shows total scope through the delivery of at least one entire project / slice (minimum of 4 sprints)
• % of epics that specify expected success metrics and where effectiveness is reviewed every sprint.

For teams that are working towards Dev Ops, the following could be a leading indicator of organizational dismantling of ingrained silo mentality:

• % of stories deployed to production with an ability to enable/disable at will (example by using a dormancy flag)

If anyone has used or is using these metrics and could provide additional insight, I’d love to hear about it.

How to Develop a Presentation

In an earlier post, I had discussed the training library that I was encouraged to develop as an Agile coach, and a reader asked if I can explain how to create a presentation, from the original idea to the final version.

Obviously the process varies considerably for each individual and often in each instance, so I’ve tried to recreate the process behind two of my older presentations for illustration.

One of the earliest presentations I developed was prompted by an experience back when I was a ScrumMaster. I had noticed a great deal of conversation and comments about metrics, both within our team and within the context of our larger conversation. I helped highlight the topic in our next team retrospective and the resulting discussion was interesting but incomplete.

With the team’s agreement, I put together an overview of what metrics were being tracked at the team and the organization level along with examples of our data and we discussed what the metrics revealed – as well as what they didn’t for us and for people who were viewing our team just from the metrics. The slides from that team discussion became the foundation for a presentation titled “Measuring Agility” which I have used in multiple instances.

Another early presentation came about because of a bit of serendipity as well. When I was living in Atlanta, I had the fortune to volunteer with the PMI Agile Forum – where I got to meet a bunch of truly awesome people and really began to feel part of the larger Agile community.

In a discussion with a fellow attendee (Hi Megan!) after a forum event, the topic eventually turned to how to do/be Agile if your current job isn’t ready for Agility yet.

We brainstormed all the ways to be Agile outside of work – keeping up with your own to-do list, managing a household on a weekly basis, keeping track of kids and chores and activities, writing a book, planning a wedding, etc.

So that eventually turned into another presentation topic called, “Agile principles for personal productivity”. Also, I’ve used individual elements of this slide deck in other training decks.

As I am writing this, I realize that this happens quite a bit: I explore topics to satisfy my own curiosity and I’ve trained myself to take notes and collect illuminating data, quotes and graphics*. Most of this material ends up in one training deck or another, sometimes in a context very different than what I had originally intended.

And sometimes a single point is relevant to multiple topics so there is quite a bit of mixing-and-matching. In fact, I now have a master file, where I simple collect interesting bits and pieces just for that purpose!

* One point I should have explicitly spelled out is to please be sure to document where you’re gathering source material from so that you can credit properly. In my experience, the Agile community is generous in sharing information but there is also a corresponding emphasis on giving credit where it is due.

Developing a Training Library

One of the best pieces of advice I received about being an Agile coach is to develop and maintain your own training library. It’s come in handy any number of times, so I’m happy to pass it along.

If you’re working for a company, then they might have standard training materials that you work from, but not all companies have the most current, relevant materials, so be prepared to update/modify as needed. There is always the bonus that it is easier/better to deliver training when you’ve been responsible for organizing the content!

I’ve found that the process of creating my own training materials served multiple purposes: forced me to develop my own point of view and organizational flow around the most standard Agile concepts and helped me to have ready responses for the most common questions and scenarios.

Among the most frequent training topics requested are:

• Agile 101 – a whole day introduction to Agile; includes the history and principles of Agile as well as an overview of any specific frameworks the client will be using, such as Scrum, SAFe, etc.
• Software Development with Scrum – usually scheduled for about four hours and is most often delivered to teams; includes information about the Scrum framework, roles and responsibilities and planning/workflow of a sprint as well as overview of planning and estimating
• Delivering with Kanban – usually 2-4 hours again most often for teams; addresses the what, when and why of Kanban; an explanation of Lean, value streams and flow and Kanban-specific metrics such as cycle time, etc.
• Introduction to SAFe – this is usually a lunch-and-learn session so would be a high-level overview of SAFe concepts and structure. I usually customize it to focus on whatever area I think an organization is doing well or really needs to improve.

Another common set of training is role-based, so:

• Agile Testing – covers topics such as differences from waterfall; what kind of testing happens when; how to partner with developers and BA, rather than working in silo mode, etc.
• Product Owner Training – this is one of the most frequently delivered since this role is new in Scrum and represents a big leap from their previous work
• Agile Project Management – most often a 1-2 hour discussion session with project managers on how to survive in a Agile world; emphasis is on the switch in the project manager’s focus from task/people management to empowering the team and  focusing on removing barriers
• Requirements Management in Agile – usually for business analysts; covers the work intake process and Agile values such as prioritization and the business-development partnership. This is the one I most customize for each client since there is a wide range of structures and roles related to this process

Then there are the training sessions to address specific scenarios, especially if you notice a pattern of recurrence. In my experience these have included:

• Agile Planning and Estimating – for teams who’ve struggled with estimation
• Release Planning – for teams/projects that are trying to implement SAFe
• Iteration Zero – lesson learned while working in government space!
• Agile Architecture for Tech Leads, also includes specifics about a tech lead’s responsibilities during a sprint, during planning, etc.
• Metrics for Management – provides an overview of the most common Agile metrics and emphasizes that metrics are a starting point for conversation
• Dev Ops – this has become a buzzword with my clients, so I’ve put together a basic slide deck on what is Dev Ops, what needs to be done before you can do Dev Ops, etc.

This post isn’t meant to be exhaustive, but I hope it provides a good starting point for anyone who wants to be an Agile coach or ends up in that role.

Measuring Value, 1

Are we doing Agile? Being Agile? To what degree? I’ve asked myself this any number of times and I’m guessing that you have or that your clients have.

I’ve certainly felt like Goldilocks at various times in my personal Agile journey. This organization is not doing product ownership properly. This organization is losing value in the release process. And in one way or another, they were flawed in their execution of one or more Agile practices.

But they were Agile to some degree at least. And they were a vast improvement – in delivery, productivity, value and satisfaction – than my previous non-Agile work experiences.

How can I quantitatively and/or qualitatively measure the level of agility in a team, project or organization and thereby providing a shared frame of reference for discussions with clients?

I’ve continued to work on the organizational assessment framework I’ve outlined previously. My original plan was to deconstruct each of the 12 Agile principles and brainstorm possible metrics – descriptive, predictive and/or prescriptive – for each principle.

Here are my preliminary efforts, starting with principle #1:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Obviously the key concept here is value, since not all Agile projects are software development projects. So, can we quantify value? And can we generate value-related metrics?

Here are some metrics* that possibly could represent how well we’re doing in being true to the first principle, depending on the nature of the specific project and organization:

• % of stories in backlog that are fully developed (with acceptance criteria), reviewed by team and customer, sized and prioritized – this is my most-used metric especially for relatively new Agile teams because it is an effective gauge to determine the status of the project backlog
• % of stories (in the backlog) that are assigned to business features (epics) – potentially indicates that requirements are being deconstructed cohesively from features representing business value
• % of stories (in the backlog) that include business value estimates, not just effort estimates – potentially indicates good partnership with customers or at least focus on customer point of view
• Cadence of software delivery to production – the lag time between delivery at the end of iteration and deployment to production
• Frequency / comprehensiveness of automated builds as path towards continuous integration
• Schedule Performance Index or Agile earned value analysis – concepts transferred from traditional projects but adapted to iterations as described
• Release Milestone Analysis (planned versus achieved); basically indicates whether the teams are meeting their sprint/release commitments
• % of stories that roll up to program slices (versions/themes/releases) via project/product roadmap – indicates that the organization has established that implementing Agile must goes beyond just teams
• % of features that have anticipated and delivered ROI measured
• % of demos where customers (internal and/or external depending upon project context) attend and where their feedback is captured and acted on

* Please note that many of these metrics were provided and/or recommended by some incredible Agile coaches I’ve met and worked with over the past year. The Agile coaching community has been generous in sharing information and this list is the result of many peoples’ contributions.

I intend to continue this process through the rest of the principles, one principle each week posted on Thursday.

Top 10 Agile Blogs

Below are ten of my favorite Agile blogs — they’re not in any particular order, but are just numbered for ease.

1. Mike Cottmeyer’s blog at Leading Agile

I have used several of Mike’s posts as starting points for discussions with clients in scaling Agile; they are especially helpful in providing language to develop a shared understanding.

The blog includes posts from all of Leading Agile’s experts, so I’ve found this categories page to be a useful bookmark when I’m trying to remember a particular post I’ve previously read.

2. Succeeding With Agile — Mike Cohn’s blog

Mike’s blog is a must-read especially if you’re working with Scrum. Just about every post reveals Mike’s expertise and extensive real-world experience.

3. All About Agile by Kelly Waters

An excellent resource for up-to-date Agile information. I have previously referenced Kelly’s posts on Scrum implementation for more than one client.

4. Lean Essays by Mary Poppendieck

From one of most remarkable thinkers and writers about Lean principles and other Agile methodologies. Not the most frequently updated blog, but contains a wealth of knowledge!

5. Fun Retrospectives

This site contains about a 100 activities that can be incorporated into not only retrospectives, as the name implies, but also in other ceremonies or any related meetings. Browse through the provided activities for inspiration to develop your own activities or select one for immediate use.

6. Agile Management Blog from Version One

Given the range of authors posting here, you’re bound to find something to help with an existing issue you’re facing or inspiration for further learning. The categories listing on the right is quite helpful!

7. The Agile Blog from Rally Dev

A number of thought-provoking posters are accessible through Rally Dev’s blog. Despite the URL, many of the blog posts are quite useful whether or not you are using their software in your projects.

8. Coaching Agile Teams — by Lyssa Adkins

From the author of my favorite book, this blog isn’t the most frequently updated, but is a must read for coaches. There are some really amazing posts in the archives, so set aside some time to browse and be inspired!

9. Thoughts on Agile Coaching by Rachel Davies

The author of “Agile Coaching”, Rachel’s strong opinions on Scrum, Agile and Coaching are always intriguing. I don’t always agree with her conclusions but appreciate the challenging perspective and her wealth of experience in Agile coaching.

10. Payton Consulting

Not sure if this series of articles counts as a blog, but since I’ve found the information to be quite valuable, I’m including it in. I highly recommend bookmarking this site; I especially loved the series on user story development.

One of the best places to discover new (to you) Agile blogs is the 100 of the best Agile blogs by Luis Gonçalves