QValue - Managing Your Technology Portfolio by Value

Over the past few years, I’ve created a Portfolio Valuation model that helps organizations develop a set of strategic value factors that when aligned with a comprehensive intake and planning process provide a value-scoring mechanism that will prioritize and fund work for their teams.  The model is called QValue which stands for Quantifiable Value.

 QValue design is based upon the Efficient Frontier model, created by Dr. Harry Markowitz.  This model is leveraged by investment fund managers across the world and provides them the ability to build a portfolio of securities (investments) that will yield a maximized return relative to accepted risk.  To simplify the intent of the model, it essentially helps fund managers develop an investment fund that maximizes the return they seek within the context of quantifiable risk.  Fund managers create investment portfolios that contain a set of securities that will be expected to provide a stable return, from which fund participants can select various portfolios in their 401k and stock portfolios to reflect their individual investment risks profile.

Organizations need to take a similar approach to manage their technology investments.  Your organization is the portfolio, and all your technology projects and initiatives are the various securities that when combined should provide a quantifiable return relative to quantifiable risk.  The QValue scoring model provides the framework for your organization to build a risk/return profile for all your technology investments, providing you with the ability to quantify value directly related to your strategies.  This represents a fundamental mindset shift from traditional cost management approaches to project funding.

You can’t effectively improve the flow of work to your teams if you don’t have an effective way of planning and prioritizing by value.  Non-value-based planning with its focus on cost benefits does not provide the most effective way to plan and prioritize with its lack of focus on value and return.  Understanding the actual return, you are getting from your team’s work, allows you to make better investment decisions and not over-invest in work that has diminishing or little value related to the cost of development.

Lean/Agile - The Art of Doing Less

Our traditional ways of managing software development projects center around generating ideas that are deemed valuable and then attempting to estimate at a detailed level the effort involved by having a team of people work to document ‘all’ of the requirements up front before the project even begins. These projects often will take many months to complete before anything of value can be delivered to the business.

Agile focuses on delivering value as quickly as possible, often within 2 weeks to 2 months. Lean focuses on maximizing work not done, which combined with Agile speaks to doing less as a part of our delivery process.

But what do we mean by less when looking at taking on a large feature/product development effort? 

There are couple of ways that this comes into play:

1.   Software is often littered with features that someone thought would be important to the customer, yet fails to deliver the value (need) to the customer. Worse still this code becomes part of our legacy application, stuff we have to code around and test against regardless if the feature is being used or not.

2.     Often the perceived value of something changes once the project begins, causing the business to pull the plug on work before it is complete and anything of value can be derived by your software development team. This is costly both in terms if financing and employee happiness.

In both cases the business has expended money to have software developed with the end result being the business received reduced or no value.

When looking at Agile Product/Project Management we are asking the business to act not just as the agent of funding but as the consumer of the work as well. Too often the business is a distant or non-existent participant with respect to how their product is unfolding. Instead they rely on project plan updates that speak solely to progress against the agreed upon scope of the project at its inception over viewing what has actually been developed and delivered to date.

In an Agile setting business needs to review the work at regular touch points, often the Sprint review and actually see what is being developed. There is often a great difference between what the business ‘thinks’ they want and what they actually need. Seeing working software lets them see their idea in action, often with enlightening results. What they envisioned may not in fact be what they are seeing and more importantly not what they need (the value). They funded a Ferrari but maybe only needed a good old family sedan.

Business is typically missing in this very powerful process in Agile, a process which allows them to make course corrections and even stop working on features as soon as they reach their maximum value. 

At one large entertainment organization I worked for several years ago, the business had us working on a large rewrite of a heavily used widget that resided on hundreds of thousands of pages. After performing a Discovery and Story mapping session we determined that the work should be done in three releases. At the end of the first release the business reviewed what we had completed and decided that this was actually good enough and then pivoted us to working on an even more valuable redesign of a key customer facing web app.

In the waterfall days the work that we did for that first release would have been put on the shelf, the money invested would have delivered no value to the business. With Agile we were able to complete the work and deploy to production, providing the business real value for their investment. They made the decision to stop this work and move on to more valuable work.

The Art of Doing less is about developing more mature approaches to how your organization funds and manages work. Instead of funding projects fund your teams, allowing for work to flow to them over having them focus on managing project scope to the bitter end of the project.

Move away from believing you have to have fixed scope to one that understands that Agile is about powerful flexibility and maximizing the value of the work that we do, while minimizing the amount of legacy code we leave behind. 

A legacy system that is littered with large amounts of un-needed or under-utilized capabilities is code that is harder to scale, develop in and test against. When your teams talk to you about Tech Debt, this is what they are referring to and as a business you are both a direct owner and contributor to this reality.

The Art of Doing less brings with it a greater ability to maximize an organizations investment in its software and product development.

The focus for business should be on what is needed not what is wanted. Project funding models encourage asking for more than is needed so one of the first things you need to do is to move to a team based funding model. Develop a framework to assess value and risk so you can appropriately prioritize work as it flows through your teams.

Understand that each of your Scrum teams has a fixed cost (~40k per sprint), this should guide you further in questioning what you want your teams to work on.  At some point in time in most projects there comes a point where there is a diminishing value relative to the investment.  

Lean and the Art of Doing less requires changing your organizational mindset to understand there is also value in work NOT done.

Moving from Project to Team based Funding in Agile

When we move to Agile we typically form our teams and then happily keep our waterfall project based funding structure in place.

We do this for a few reasons:

1. We think it’s the only way to show the cost of the work that we are asking to be delivered.
2. Projects are easily understood from an operational standpoint as they have a defined start and end date which is tightly aligned with the cost of the project.
3. It’s the way we’ve always done it.

As part of our project based funding model we have an annual project funding request process, where we  spend weeks/months identifying the things that we think are important (note I’m not using the word valuable here) so that we can obtain funding.  Things move above or below the approval line and when the dust settles we have a book of work that is committed to, with freshly minted project plans and a cadre of project managers to manage the money we just gave to these projects.

An annual project funding request process also means that we ask for what we need and then everything else we may or may not need.  We ask for a Ferrari when perhaps all we need is a good dependable family sedan.

There is power in money, who has it and who controls it typically drives what gets funded and what doesn’t.  It’s not uncommon for Sr. Leadership to commit to work even though their team doesn’t have any experience in the product solely to get the money to keep their teams funded and employed.

If you see a lot of potential waste here then you are correct.  We see waste just in the amount of people and money needed to manage our project money.  If a money market fund had as much overhead associated with it, I and everyone else would leave because that overhead just cuts into profitability. 

Next let’s more waste related to developing the stuff we didn’t need and may not actually use.  All of this extra stuff we develop has an expense associated with it and this is a long term expense.  We have it built into our architecture negatively impacting our systems scalability, performance and security.  We have to test it every time we build new stuff.  Bet you didn’t take that into account when you did your Cost/Benefit analysis for the project.

When we move to Agile we have an ability to really simplify our IT funding function.  It’s really quite simple – it’s the cost of your team. 

In most organizations this cost typically hovers around ~$40k per sprint or over ~2 million annually.  So as a financial manager trying to manage things like cash flow, depreciation and the like, this makes financial reporting much simpler.  Each team becomes a fixed line item cost on my balance sheet and operating statements.  I don’t have to worry about cost overruns from project funding since the team is a fixed cost.  Product Owners ensure our teams work on the most valuable things in a consistent manner and at the end of the year we should/can be able to gauge the value of that work to some accuracy.

So here’s a challenge that we face, how do we actually assess value?  How do we value things like reducing technical debt to make applications technically better?  How do we value writing an input validation security framework that makes our application safer for the user and ourselves?  How do we value things that our customers aren’t asking for, but in the end benefit from?  That is the core element of software development, there is significant value in the things that the customer never sees yet we place little effort or priority in delivering these elements.  Instead we focus on the visual functionality and throw quality and architecture down the drain in favor of meeting project timelines.

If you get the fact that you have a fixed development cost it actually should foster better conversations regarding what is really valuable for the entire organization to be working on.  Not your pet projects, not the projects you agree to only to get funding to keep your people employed, that’s not how real value and efficiency happens and it’s time we stop thinking that it does.

Agile highlights very quickly that an organizations planning and funding functions are broken. It also typically becomes clear that we don’t have a real grasp on what our real value streams are and finding them often means removing political barriers that have built up over years.  Agile requires that we redefine what value is and organize our delivery across these streams over organizational silos.

The traditional PMO also goes under a dramatic shift, moving from managing projects and funding to ensuring that programs align to the organizations value streams, are well understood and organizational impediments are removed for the teams.

So if you are looking to move your organization to Agile you must understand that your funding and planning functions must change to align to a new mindset and paradigm.  Funding is easy in Agile, really it is (remember it’s the cost of your team), uncovering your value streams and maximizing the work that flows to your teams that delivers that value, now that’s harder (but not impossible).

Delivery Management vs Project Management

In Agile we have evolved from a 'project' oriented mindset to a product one. That is not to say that we don't undertake a something that looks like a project to build or enhance our products.  However in Product Management we are more focused on the ongoing nature of how our product will unfold, in shorter durations and without the end in site.

I believe successful Agile Project Managers need to focus on Delivery Management over Project Management.

What is the difference?

1. Delivery Management - Is the management of work in an iterative fashion that focuses on delivering product that delights our customers.  It is not focused on Time, Scope and Budget, but rather on customer experience, high quality code and low defects. Delivery management focused on long-term value and benefits over planned short-term objectives.
2. Project Management - is the application of processes, methods, knowledge, skills and experience to achieve the project objectives. A project is a unique, transient endeavour, undertaken to achieve planned objectives, which could be defined in terms of outputs, outcomes or benefits.

Having been a project manager in a waterfall/PMI world before my move to Agile some of the mental challenges I faced included:

1. Lack of a plan - One of the first things I did as I was moving to Agile was to track the amount of 'change' that happened in one of my waterfall projects.  I created a Project Change Request for everything that was not originally identified in the Business Requirements and Technical Design Documents, assumptions that changed, scope, etc... This process drove my team absolutely crazy because as with all waterfall teams, we fear change requests, they are bad news to management.  However what this effort did was provide visibility to the type of change that happens in every single software development project (and these changes were never socialized outside of the team so they had nothing to worry about).
   1. Realization - 
      1. My project plans provided no real ability to know if a project was going to be successful, they looked good but didn't tell the real story of what was happening with the project team and what they were developing.
      2. Agile provided me with much more visibility to the real issues that a project team faced and that my project plan was really just a place holder for future Sprints.  I only needed to know that the Sprints were planned and then communicate what the team was committing to.  Once I had that information THEN I could hold them accountable.
2. Story Points over Time bases estimates - I had a really hard time initially wrapping my head around Story points over time and spent many an hour mentally putting the points back into hours.
   1. Realization -
      1. I finally stopped thinking in time once my team started 'delivering' consistent points and work for every sprint.  At that point all I ended up needing to know was the story points of work begin committed to.  The point here is as a Project Manager you need to instill good estimation behaviors with your team and hold them accountable, that IS your job.
      2. Velocity is the primary data point you want to focus on, consistent velocity = consistent delivery.  It's not your job to determine the What for the product but it is your job to ensure that what they commit to does get Delivered (though if you work to be a valued member of the team, you should definitely be able to provide input).
3. Status Reporting - Ah the bane of our existence as project managers and something that I had to deal with recently, the dreaded status report.  Honestly I hadn't been a project manager for many years and as a Manager I never needed one with Agile teams.  All I needed was a dashboard (Jira or Rally are the ones I'm most experienced with) to observe a teams backlog, Velocity and Progress towards a Roadmap they were working on.
   1. Realization - The status report will not every go away but I think you need to ensure that your reporting is consistent with the rest of your Agile processes.  Tools such as Jira and Rally provide you with abilities to manage Roadmaps, teams, budgets, etc... Everything is still there but your reporting needs to take advantage of the data elements within Agile, don't translate your Agile into a waterfall type status report.  This will only ensure that Sr. Management stays disconnected from Agile and the entire organization needs to be plugged into Agile and walk the walk.

If you are a traditional PMI type project manager and are moving to Agile here are some things you should consider:

1. You are not responsible for the success of a project/ delivery - Yeah I know it sounds wrong, but in Agile it is the TEAM that is responsible for delivery.  You need to plug into your team, get to know what they do, the challenges that they face, become a sounding board for ideas, get your hands dirty, learn how to test, etc...Becoming a valued member of the team is what moved me out of Project Management and into Quality Assurance. 9
2. Be an Agile advocate - Embrace agile so that you do more than go through the motions. Read, learn, join a meet up group, do more than just the minimum.  As a Project Manager you can help your organization get better at Being Agile, you have the connections and understanding of the organization that many in the technical side may not.
3. Don't be Defensive- As you will learn, Retrospectives should be frank and open conversations about what is working and more importantly not working in your processes.  Encourage your team to openly talk about issues, but protect them so that they can continue to work effectively as a team, remember attack the problem not the person.  For example at Disney where I both QA Manager and individual contributor my duties as QA Manager were getting in the way of my ability to test and give good feedback to the team.  They rightly called me out in a retrospective as being the issue for them not moving as fast as they could.  I was not defensive but understanding, that is what you want in Agile, because they were absolutely correct, I was the problem at that point.

So as you look at what you manage in traditional project management, understand that it is not the Project that you are delivering but a Product and Products have much longer life spans than projects.

You need to keep your teams focused in consistent and disciplined delivery that brings real value to your organization. If you are working on something that doesn't have value you should be questioning and challenging your team as to why.

Agile isn't easy, though I think it is often thought of as easy.  No Agile is very disciplined and when you undertake Agile it will highlight every inefficiency and poor process that exists in your organization today.  You simply cannot go fast until you address these issues.  As a Project Manager you can help drive this change.

Agile Planning - I have a need a need for speed

Working at Disney a number of years ago was in so many ways transformative for me (not sure why I left) because it provided me with an opportunity to work with an organization that needed to get better at delivering software for our partners and we ended up choosing Agile as our path. Disney was the place where I had the opportunity to help build an Agile process from Requirements to Delivery and what we discovered was that we needed to develop an effective planning process that allowed us to build a solid backlog of work before we just started coding.  I here that so often in organizations that are just starting to adopt Agile.  I think a statement I heard recently is descriptive of organizations that just start coding - Shoot and Point.

Disney is a largely creative driven organization (Not surprising) and because of this we typically had a disconnect between our creative (UX) groups and the Product Delivery teams.  The UX team primarily worked independently of the PD teams and as was the case when I arrived, UX would deliver a creative design that didn't align to our technical capabilities.  This is a common issue in today's web development environment.

Our first 'Release' Planing went very poorly and after a round of retrospectives we came up with a format that at first pass you would say wasn't Agile (trust me we used that phrase a lot in the early days of our becoming Agile).  But in the end this first step of Discovery ended up being what I believe is the most critical element of being able to go fast in Agile.

The basic process that we ended up with was as follows:

• Pre-Discovery - Sr level PD, PO, UX, Marketing and other Stakeholders would review a specific new feature that was being considered. The group would utilize several tools such as Mind Mapping to understand the scope, parameters and potential dependencies at a high level.  If the feature work was approved then we went to the next phase.
• Discovery - Depending uponthe the size of the potential project Scrum teams and extended stakeholders would meet to go through a low-level review for that feature development.  For many of our larger efforts it was not uncommon for us to sequester the teams into a room to work through the entire effort, UX to QA to Delivery.
  • Process
    • Kick off - Have your PM or PO along with the key stakeholder(s) of the effort describe WHY this feature is so important.  We learned in our process development that it helped our PD teams to have an understanding as to why this feature was important to the organization.  It helped them feel connected to the value that was being delivered and not simply code jockeys running a race.
    • Competitive Review - Another great exercise was to have the entire team go out and find competitive features that we either did or didn't like and describe why.  This helped the next phase of our Discovery process as we worked to define what our feature sets would ultimately look like
    • UX and Story Development - This was the primary scope of our Agile workshops.  Typically led by the UX lead for the project we would begin developing low-fi wireframes and discuss the issues, constraints and code complexity that the low-fi would entail.  We discovered in this process that we could work through the types of issues that come much later in a typical product delivery effort.
      • Outcomes -
        • UX ended up with designs that they could utilize to develop prototypes that would be used in User testing prior to any significant development work being completed.  This allowed changes to UX to be found at the very beginning of the PD process rather than at the end when refactoring consumes a much larger amount of time and leads to lower quality of code.
        • PD ended up with a solid design at the beginning of the PD process which led to high quality code and higher levels test automation.
        • QA ended upon with an ability to write higher quality acceptance criteria which lead to high quality in the delivery and higher levels of test automation (sensing a theme here?)
        • User Story development was done during the Discovery phase and with it I was able to have a fairly accurate model to predict the number of stories at the beginning of the Discovery phase (typically between 100-120 higher level Epics, we strove for stories to be between 21-34 points in this phase as PD would start fairly quickly after the discovery phase 2-3 weeks) and how many that would translate into for a full project (typically 350 - 400).  This provided me with input as to how many BDD acceptance criteria would come out of this as we used a marker to determine when a story should be broken down - More than 7 variables in the BDD would be an indication that it's time to think about breaking down the story and more than 14 tests in a single test scenario would also trigger the conversation of whether to add a scenario to a story or create a new story.
          • Benefit - Keeping your BDD test automation in small increments makes it much easier to understand what broke, who probably broke it and what is needed to fix it.

I know this doesn't 'Sound' Agile (like the name of my company), but in my experience doing this small amount of work up front does provide teams the base to go really fast once the PD process begins.

I have used this process now for many years and when we do it right it's like writing a symphony, all of the moving pieces make beautiful music.  When it isn't done right, then all you get is noise.

This process probably does work for larger and more complex organizations over small organizations, but really would you start building a house with no blueprints and no idea of what you wanted?  If you had builders just show up and you told them I need a house to live in and I need it fast you will get that, but I doubt it will be anything that you want. And in reality it wouldn't be done fast as they probably wouldn't have the right materials scheduled to arrive at the right time.  I have my roofing supplies but the foundation company can't some for a month, see what I am getting at?

Slow down a bit, understand what you want, how to get it and then go fast to get it.

PMO Role in Agile - Part 2

My initial blog seemed to have some interest judging by the number of views it's received so I'm guessing that it's a topic that many are looking for input on.   So I thought I'd provide some more thoughts as to what a PMOmight  look like in an Agile organization. One of the key things that changes with a traditional Project managed organization is that they must change to one that is Product managed.  What this means is that the organization changes the way that it funds its business by essentially providing Product Owners with Scrum teams that will deliver on their vision for their product.  Given this paradigm, along with the creation of the Scrum Master role, the PMO and subsequent project managers are left outside looking in.

Managing Product driven teams means that you are managing towards outcomes that delivery value over projects that deliver features.

In my previous post I provided some suggestions as to what individual Project Managers could do to make themselves more valuable and productive to their teams.

In this post I will suggest a PMO structure that focuses on the Portfolio view and leaves the operational execution of the roadmap to the Scrum Teams and Product Owner.

For this structure to work the organization needs good Scrum Masters and preferable ones that aren't also individual contributors for their team.

The structure of the PMO will be lighter than you might think is right, but I'll argue that if you have the same number of Scrum Masters and Project Managers you will set up role confusion that will make your entire project management process cumbersome and less productive.

The PMO structure would look something like this:

I think one of the things that a PMO organization needs to be aware of is that their focus is not on control of projects and people but on how teams are performing.

With this structure you have a thinner level of Project Managers who are focused on Program level Product Management (PPM new acryonym anyone?). Your Project Management function becomes one of oversight of Scrum Masters and working closely with Program Managers in other Product groups who probably will have cross org dependencies.  The Program Manager level in this structure is more about working to ensure that teams are working on the right things based upon the Product Roadmap and escalating when individual team priorities become out of line with the overal corporate product objectives.

What we want with a PMO is confidence and how we do that historically is to place controls, gateways and processes designed to show that teams are checking off boxes that we believe represent how a successful project should unfold (aka Project Governance)

How we do that in an Agile organization is to ensure that our teams we have a clear Product roadmap, that we are performing effective planning both in the areas of Product Discovery and Release Planning, that teams are provided time to review and estimate the work that they are being asked to commit to AND ensure that teams perform continual inspect and adapt cycles via Retrospectives.

If teams are allowed to form into solid high performing teams what you get from that is an organization that learns how to estimate accurately, which leads to consistent velocity which in turns leads to predictability....which is what we in the PMO (and Sr Management) are looking for, simple right?

What I learned years ago from my Project Management days is that Agile actually provides you with much more visibility and transparency about what is happening with your commitments,  providing you as the stewards of the product an ability to have fact based conversations with stakeholders who rarely understand the complexity of what they are asking for.

Being Agile - Say it, Do it, Prove it

I was working with a team recently and as we talked about all of the planning that Agile entails, I broke it down into very simple terms - Say it , Do it , Prove it. That is really what Agile is about.  Anything else outside of these three concepts is noise to your ability to deliver product and services to internal and external customers.  As Product Owners in an Agile organization, you need to understand all of the effort and dynamics involved in getting your teams to Say it, Do it, Prove it.

Delivering what you say you are going to deliver is the best way to build credibility with your stakeholders.

For Agile teams, this translates into being effective at decomposing your stories into small enough increments so that you are confident in your understanding of the user story and estimates that the team believes in.

1. Say it = Release Planning and Backlog Grooming -
   1. Starting at a high level, the Product Owner is responsible for saying what is important to the organization from a value standpoint and beginning the process of developing a user story backlog that supports this vision.
   2. User story decomposition is so important to effective Agile teams and the Product Owner must start with a set of well-formed stories that provide context to the team.
   3. What is 'context'?   Context is anything that provides definition.  It is basically what the product should do from a functional standpoint.  One of the biggest mistakes many teams make is writing declarative stories that start with the 'How'.  This,\ in turn,  puts the technical team on the defensive as they may have many different ways to implement the feature.  As a Product Owner, be sure to steer clear of writing stories that define how you think the feature story should be implemented.  I know that as we all become well versed in technology there is a strong desire to show off our technical chops, however, as a PO you need to provide context from a business standpoint that your tech teams can consume. I've heard time and again from engineers that they would really like to understand how what they are developing delivers business value or solves a particular pain point for the customer.  The team works much more effectively when they are completely grounded in the business context of what they are building.
2. Do it = Sprint execution 
   1. An important element for teams to address once they are ready to take stories into a sprint, is that the goal during the Release Planning and Backlog Grooming activities was to begin to build out the context of 'How' the story will be implemented.  It is so important for teams to understand that there is essentially a handoff from the PO to the Scrum Team and that each of them is responsible for building what I call contextually rich user stories.  Gojko Adzic calls this Specifications by Example.  Effective teams who deliver fast and with high quality work closely as a team.
   2.  I believe that the combination of User driven stories and context driven specifications (examples) forms an extremely strong definition of both Ready and Done. which is why I coach my teams to utilize BDD as the basis for developing their User Story acceptance criteria.  The team works together to complete BDD acceptance criteria forming a clear understanding of the boundaries of the feature.  This provides the PO with a concise view of what to expect during the Demo.
   3. Another key benefit of writing BDD as part of your user story writing is that the test automation engineers can easily consume this as part of their code development for the automation.  PO's should push to get to this level of context as it also means that your test engineers can start developing their test automation code once the story is ready for development.  They can essentially perform TDD in that they can write their automation before the feature is actually developed.  Once developed the automation should run cleanly and both speed and quality are attained.
   4. The goal of teams should be to deliver user stories that do not require much further elaboration once the sprint begins.  You want your teams focused on delivery ,not on discovery.
3. Prove it = Retrospective
   1. You have done all of the work to clearly define your user stories with high levels of context.  With all of this effort, the Retrospective should be an easy affair to show the work that was defined in the stories.  The PO should not have any surprises.  In fact, if the team misses any test scenarios after the story has been started, the PO should consider that more of a missed requirement over anything else.  Since the entire team developed the stories,  there can be no finger-pointing at anyone.  It was a shared miss and everyone must accept it.

It sounds really simple when broken down into these 3 basics phrases.  The truth is that 'Being Agile' is much more involved than simply 'Doing Agile'.

"Being Agile" means exposing all of the inefficiencies in your product development processes.  It requires that the organization be completely honest in assessing what is not working and committing to letting the teams that do the work fix these processes.  You cannot top down drive the type of organizational change that is required for Agile continuous improvement.  Real organizational change is fostered at the top but truly owned by the Scrum teams that form in support of any Agile adoption.

Agile Discovery - Addressing fixed date/scope projects through upfront planning

Most of the Agile projects (perhaps all) that I have worked on over the years have started with an express understanding of scope AND a fixed date for the delivery.  One of the common myths I think people have about Agile is that when you 'go' Agile this issue goes away, it doesn't. By ignoring the need for some level of planning prior to taking on an Agile project, teams start with a deficit of knowledge (ie well groomed story backlog).

I'm a huge proponent of having teams take on their project backlog with an initial Discovery workshop that includes the entire team and can take anywhere from 1-5 days depending upon the size and scope of the project being considered.

I've used this approach to plan out a 6 month release with tremendous success, typically delivering more value than the stakeholder asked for and with virtually no defects.

I think this planning effort is key for teams to realize high levels of iteration productivity.  The time to build context in your stories and features is not after the iteration (or train) has left the station.

Many of you, especially Product Owners, will make the assumption that it's a waste of time for the team to perform a Discovery session that builds out stories and acceptance criteria at a lower level for more than an iteration out.  The concern that everyone has is that if we don't start coding immediately we'll be behind and won't make our commitment.  The truth?  Having a user story backlog that is well formed and understood by the team allows the team to stay focused and productive over trying to design and address context while trying to actually code the feature.

What do I mean by Discovery?

Once a team receives a project from their stakeholders with a set date for delivery, the 'scope' of the project then becomes the key to meeting the delivery expectations.

If the team just starts coding with the first few stories that are available they are already in story deficit, they don't have enough work to keep the iteration engine going, meaning Backlog Grooming, Pre-Iteration Planning and Current Iteration planning.  High functioning Agile teams understand that the iteration engine only works when you have a product backlog that is clearly prioritized, has sufficient context and can be worked on with no real impediments.

For example if a team has a six month project which consists of 12 two week iterations the team needs to identify the following:

• Story Themes - What are the functional slices of the features/product you are delivering.  Themes form the basis for building your release plan.  Themes will hold the high level user stories that are identified in Discovery, typically greater than 40 points.
• Epics - These are the larger User Stories that are identified during discovery as they relate to the Story Themes.  These will typically be larger than 40 points.
• Features - As Epics are decomposed they are further brought into focus as distinct features that can be worked on a independent units of work.  Features will typically be sized between 21-40 points and have a much greater shared understanding by the team of what it will take to deliver this.
• User Stories - As teams continue to decompose Features that are able to get to the granular set of work, complete with Acceptance Criteria (such as BDD).  These are the items that are addressed in iteration planning.

My experience over the years has seen teams be able to spend anywhere from 2-5 days working through the Themes, Epics and Features such that we have a strong understanding of how the project will unfold from a release standpoint and a lower level set of Features and User Stories that help UX work ahead of the Delivery team.  This process has proven successful for the teams I've worked with who have tried it.

I'm not suggesting that an entire 12 iteration project needs to be flushed out to the user story task level, however getting further than the Epic level with a few features and a few stories will allow teams to be very focused on iteration level delivery on a consistent basis.

This effort can provide a higher level confidence level for the team with a small spike of investment in upfront planning.

Planning is an important element of successful Agile teams, don't short change it when working through new features/functionality.

Hurdling through Product Delivery part 2

Product delivery is a discipline that requires the involvement of all segments of an organization:

1. Customers and Stakeholders
2. Product Owner
3. Scrum Master
4. Delivery Team - UX/Dev/QA
5. Operations
6. Services and other specialized teams that touch the product in anyway as it moves from concept to delivery to production.

As I mentioned in my previous entry, maximizing the smoothness of product delivery is like running the hurdles.  How so?

What happens when you first start running the hurdles with no experience?  You stand at the starting line and then you start to run.  As you approach the first hurdle you try to determine how you are going to make that first jump.

Is that first approach smooth?  Probably not.  You probably came up to that first hurdle and maybe stutter-stepped before trying to jump or even had to stop before you actually tried to get over the hurdle.   Why?  Because you didn't know what to expect, you didn't know what you didn't know as you ran toward that first hurdle.  Maybe you made it over all of the hurdles but it probably wasn't pretty, perhaps you fell a few times in the process.

So with skinned knees and wounded pride you make your way back to the starting line and you try again and again and again.

In this process you are setting your baseline performance.  Are you getting better with each attempt?  Hopefully....because we really want to be a successful sprinter.

As you continue training, perhaps even getting a coach, you start to break down your individual steps as as you go from hurdle to hurdle.  Over time and through practice and experimentation you make small changes in order to maximize your speed and efficiency in getting to, over and past each hurdle.  Not paying atttention to how you land after a hurdle means you may not approch thet next hurdle most efficiently.  As you continue this practice and feedback loop (Retrospective) you can begin to reach ever higher levels of speed and success.

Eventually you don't see the hurdles, they are just part of the process of completing the race.  They aren't obstacles anymore.

This approach is how athletes get to world class levels.

How is Product Delivery like running the hurdles?  With each step from ideation to delivery there are hurdles that we face that keep the entire delivery process from being efficienct and effective.

And more importantly, whereas a sprinter has the luxury of knowing that their hurdles are 30ft apart and either 39"-42" tall, Agile Product Delivery teams don't always know where their hurdles are at, but through effective use of Scrum, teams can begin to identify where the hurdles are and start the process of learning how to approach and exit each of those hurdles, using Retrospectives.

We too can get to a point where our hurdles are just part of the process and if you aren't running the hurdles anymore what are you running?  A sprint.....

What are some of the common hurdles that we face in Agile Product Delivery?

• UX Design not clear
• Lack of Product Vision
• Poorly formed product backlog/user stories
• Lack of technical excellence - Continuous Integration, Automation, code reviews.

Successful Agile delivery is all about identifying your hurdles, getting them lined up appropriately and working to maximize the efficiency of the steps we need to take to get to the end.

As with world class athletes we need to continue to evaluate our approach and drive world class product delivery for our customers.

Delivering Software Fast is Like Running the Hurdles

I had the opportunity to attend a couple of Dan North's Deliberate Discovery sessions at the Better Software East conference this month and as he talked about how we want to deliver software faster I started to envision that delivery of software is much more about running the 100 meter hurdles than it is about running the 100 meter sprint. With the 100 meter sprint the runner knows that from start to finish there are no obstacles and that they can maximize their speed through focus on the finish line.

Organizations aren't like that, we pose so many different hurdles that even if you believe that you are running a sprint, in reality you are probably running the hurdles.

With hurdles a sprinter must continue to work on the way that they will approach the first hurdle and then the next and so on and so forth.  Along the way anything might 'trip' them up.  When they clip the top of the hurdle they have to make adjustments almost in mid air to try to recover.  The ability for great hurdlers to continue to work on their approach to each hurdle ensure that they can run fast competitive races.

Software development is very much like the hurdles.  Even if your Engineering team is able to deliver features quickly, if your Product Development or QA groups aren't aligned with that speed then no matter how fast you run between one hurdle you will be struggling to make the next one because you haven't optimized the steps in front and behind the hurdle that you do well.

In order to deliver software fast organizations need to look at each of their Product and Software Development cycles so that each one maximizes the delivery of the previous steps. More to come on this......