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.

  1. 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.

  1. 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.

  1. 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.