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.

PMO Role in Agile

If you lead a PMO or are a PM and your organization is embarking on an Agile adoption you are probably thinking so how do I fit into this new paradigm and still manage the work that I'm currently managing (it won't manage itself is what you are thinking) ?

Organizations who are now moving towards Agile as a product delivery/SDLC method will find themselves trying to figure out where their PMO and subsequent Project Managers will fit.

The problems they face are several:

Traditional Project Managers:

• Are experienced at managing to a specific plan and resolving resource issues that their specific projects are facing.  They are not typically assigned to just one project and the people they work with come and go with much frequency.  Project Managers have been for many years the ones who provide confidence that 'someone' has their hands on the pulse of the projects that are designed to deliver value to the organization.
• Don't typically look at their projects as value driven, rather they are priority and resource driven.  Their focus when they are assigned to a project is about who is on my team, who can I steal from other projects and creating a plan that is often not vetted by the very people who will actually do the work and socializing that with Sr Management.
• Traditional Project Managers are excellent deflectors of blame (yep I learned quickly how to push off issues on to someone else)
• Are not typically contributing members of the team.

I don't say these things to make Project Managers angry, I was once a PM and a very good one at that (or so I believe).  And I'm not at all implying that there isn't a role for PM's in Agile, but I will suggest that how you think as a PM will need to change.

For starters you need to find a way to be a contributing member of the team and not just someone who sits on the sidelines like a reporter and records what is going on to report out.

The thing that was different about me was that I always managed my teams more like a Scrum Master would.  I found ways to contribute, I gained the trust of my team, I protected them and provided guidance for individuals when they were struggling with something about the organization that didn't make sense.  This process of engagement led me out of the PM role and ultimately into QA Management so there are growth opportunities for PM's if you are open to learning new things.

If the team needs help in testing, learn something new and help out.

Most Agilists' may tell you that the Scrum Master and Project Manager role are completely different.  Though they are different I would argue that project managers can fill the void of Scrum Master and gain great insight to their projects and be on point to resolve impediments more easily than be bystanders to the entire Agile process.

Here are some key areas that Project Managers should focus on during an Agile Transformation:

1. Planning - Is not a function of setting forth an unyielding plan.  Rather planning by the team is to facilitate an ever growing understanding of what the team is building.  Big Up Front Requirements convey a static nature to projects that simply doesn't exist.  If you disagree actually track the number of times the team has to change their plans (for architecture, etc..) during a typical non-Agile project.  Teams that try to predict the future are destined to be wrong a majority of the time.  You need to become comfortable with a plan that identifies in detail only 4 weeks out.
   1. Goal - Be an active member of the team and be able to understand both the technical issues that are facing the team and bring them a clear understanding of dependencies with projects and teams that aren't in their viewfinder.
   2. Goal - Learn different Agile planning techniques.  One of the key things that people miss in Agile adoption is that Planning needs to take place more often and that some level of upfront Discovery is not a bad thing.
2. Scrum/Agile  Activities - A Project Manager for a Scrum Team needs to:
   1. Ensure that their teams are performing effective User Story development with techniques such as BDD and Specification by Example.
   2. Ensure that their teams have a well groomed set of stories in their backlog
   3. Ensure that their teams have effective Sprint Planning and Estimation sessions
   4. Ensure that the teams utilize their Retrospectives to drive continuous improvement
      1. Goal - Become an Agile evangilist, learn everything you can about Scrum, Story writing, TDD, Continuous Integration, User Story Mappiing, BDD, Specification by Example.
3. Program Management - Is driven by the overall roadmap.  Ensuring that Scrum teams are aligning their user stories to appropriate Road Map Items keeps the organization focused on execution progress/success and provides the PMO with a clear view to all of the work that they are managing.  As an organization scales this is no small feat, so getting large sets of teams to keep up with story writing and roadmap linking is an administrative task that teams quickly tire of.  Project Managers need to provide support and assistance with the management of these types of activities in conjunction with their PO and Scrum Master.
4. Technical Knowledge - Though this isn't as big of a problem as it was 10 years ago, many Project Managers simply don't understand the underlying technical platform that their teams are working in.  I personally don't think that you can be an effective project manager unless you have this knowledge.  Take the time to learn, your team will appreciate it and you will be able to have better fact based conversations with your Stakeholders regarding issues that delay delivery of projects.

BDD - Breaking down stories

One of the areas that many teams struggle with is getting user stories to the right level of context.  For me context IS everything in user stories.

 Yes a story is a placeholder for a conversation, but with large complex systems and organizations, the need to build out (and document) context has many benefits for teams and the organization.

Over the years I've seen some consistent elements fall out of BDD that can provide teams with an understanding of when a User Story may need to be broken down.

As you begin to build your test scenarios for your user story ensure that the story has no more than 3-4 scenarios.  If the number of scenarios is large, getting a clear contextual understanding of the story becomes much harder.  Additionally if automation is part of the equation then you end up with a larger code base for a single story and it can make trouble shooting failures harder.  Smaller stories mean less complicated acceptance criteria and more manageable and scalable automation code.

Once you have identified your test scenarios and begin writing the supporting BDD acceptance criteria look for some of these elements as queues to potentially break down your stories:

1. Large set of parameters- If you see that you have more than 7-8 parameters in an individual test scenario consider breaking the test into additional scenario(s) or another story.  As I've taught my teams, if you see your example table stretching off the page you probably need to break it down.
2. Large set of examples - If you see your test has more than 12-15 examples in an individual example table, you should consider breaking it down into additional scenario(s) or another story.

Keeping your stories and test examples small ensures that the team can more accurately estimate, deliver and demo their work consistently.

Teams should strive to break stories down so that they are small enough to be completed (Dev and Test) within 2-3 days.  This level of granularity provides clear visibility during Standups if the team is on track to deliver on their commitment.

Many teams suffer from what I call 'pushing a river down a creek' syndrome.  Meaning that they don't perform sufficient planning and story breakdown which leads them to continue to push their work out into future Sprints.  This leads to a lack of visibility as to when 'it will be done/delivered'

Breaking down stories effectively also leads teams to have stable velocities which leads to predictable delivery.  All of this feeds improved Program and Project management across the organization.

Organizations that need to scale Agile need to understand that this level of discipline isn't easy, but we shouldn't shy away from something just because it's hard.

BDD story breakdown leads to vastly improved feature definition, scalable automation suites and a strong automated regression.

The Agile Manager Conundrum

If your organization is moving towards Agile there are some specific elements you will need to be aware of from a Management perspective.

 Agile focuses on teams being self organizing and what that means for managers is that you need to give up some control, however that doesn't mean you are backing away completely.

Effective managers in Agile focus on these areas:

1. Technical Vision - This is so lacking in most of the organizations.  Most organizations I've worked for have some higher level vision set in place, maybe some standards but at the execution level these tend to ignored in favor of getting 'it out the door'.  Teams incur substantial technical debt that costs real pain and money to organizations long term.  A good manager is able to set forth operational vision for the team.  Using Scrum processes such as Retrospectives, the manager can encourage the team to come up with processes that work for them that support the vision.
2. Technical Excellence - The operational side of the vision again involves the team understanding what it takes to deliver high quality code.  Understanding how to ensure that code is refactored on a continual basis, that code reviews are not rubber stamps but should have a specific focus and structure designed to teach.  At one startup I worked for code reviews were taken very seriously and provided junior developers with an opportunity to get good feedback on how they were developing as engineers.  As a manager you need to ensure that the Alpha dog syndrome doesn't happen, good code reviews are educational not demeaning.
3. Career Development - This is probably one of the harder areas for technical managers to be successful in because I think most organizations don't provide the right type of management training to their technical management staff.  Understanding what to look for and encourage is for me the most important element of being a good manager.  Career development provides the organization with employees who are happier, more focused, more dedicated and produce higher quality results.

No where in these areas do you see the manager handling problems with the teams project planning, etc...  Though you need to build confidence in your teams abilities to deliver, you also need to let the Scrum team and processes evolve so that they(the team) handle most of the day to day issues and keep you in reserve for the important ones that truly need management intervention.

You have plenty to do as an Agile manager, it's just not what you are probably doing today.

BDD - A team oriented activity

Probably one of the harder elements of Agile that teams struggle with is the art of collaboration. Our experiences over the years have taught us to treat functional groups such as BA's, Devs and QA as separate entities each with their own perspective and each distrustful of the others abilities to deliver.  How many times in QA do we hear the phrase 'Just toss it over to QA and let them deal with it'. 

We forget so easily that what we deliver for a customer is the sum total of our efforts, not just of individuals.  The Chicago Bulls were a good team with just Michael Jordan, but only when they were able to blend ALL of the skills of the team were they able to win championships.  Scrum is about team.

Getting your Scrum team to actually work as a team is one of the key efforts that everyone needs to make and BDD is a way that can help teams  work collaboratively to  build what I call contextually rich user stories.

You can't rely on just one or two people to write user stories and acceptance criteria as there is a limit to the context of what any one person can know.  With ever growing complexity in business and technology the more people who can collaborate the more context that is captured in the story.

Does it sound like heavy overhead?  It shouldn't.  I'm sure you have all spent hours pouring over Business or Product Development documents trying to glean enough information to build a design that will work for the next 6 months (which we know doesn't happen on any planet in this solar system).  We've always spent time trying to understand what is being asked for but in Agile we spend smaller increments of time on writing details that matter.

The most successful teams I've worked with have adopted this type of approach for building out BDD acceptance criteria:

• Start of Sprint -

1. During the first two days of the Sprint the QA lead and Product Owner work together to develop (and or complete) BDD acceptance criteria for the next upcoming sprint.
2. By day three the development team should start delivering stories to QA for testing.  Additionally QA can begin their automation efforts via BDD examples with tools such as Cucumber, Fitnesse, Capybara....
3. The engineering team needs to plan to complete all of the story development so that the last two days are open for them to  review the acceptance criteria and make changes/suggestions to the PO.  The team is also completing their designs for the upcoming sprint during the last two days and fixing any bugs that are discovered in testing.

The key to this process is that before the team commits to the sprint they must all review and agree to the scope of the BDD acceptance test examples.  Without this discipline, the scope of the story and sprint will not be as precise.

As I've told my teams in the past, moving to writing BDD acceptance criteria is a mind shift in how you view both requirements and testing.  Both Development and QA can consume them for their individual efforts, but in the end, if they work against what is defined in the BDD they will both be on the same page functionally.

BDD takes the guess work out of what is being developed and that's a good thing.  For Sprints to go quickly and with high quality,  teams have to understand exactly what they are doing.  To steal from one of my favorite phrases from Bull Durham 'Don't think, it only hurts the ball club'.

BDD provides clarity for the entire team and makes demos go smoothly.

Ensuring that the team provides input, review and commitment to BDD acceptance criteria keeps everyone focused on doing just what is needed.

Behavior Driven Development is more than Automation

Recently while working with an organization going through a large Agile adoption I had the opportunity to work with a team that was open to adopting BDD acceptance criteria story development.  One of the key differences for this team was that this was the first time that they had experienced a collaborative story development effort.  Prior to this most teams in the organization looked to the Product Owner to write all of the stories, which led to stories that were not contextually rich, had little to no acceptance criteria and were difficult to demo at the end of the sprint.

As I discussed the success of the teams use of BDD I was surprised to hear feedback that indicated the organization wasn't ready for the heavy lift of using BDD and that I hadn't moved the team into BDD because their final work wasn't automated.

If that is your position then I think you are missing the point of BDD.  Yes BDD is great in that when you right acceptance criteria in the Given/When/Then format and build your example tables correctly you can obtain automation fairly easily with tools such as Cucumber, Fitnesse and a whole host of tools that have been developed to support this very successful way to build out what I call 'contextually rich' user stories.

However even if you don't automate your BDD acceptance criteria, the value you get from understanding the behavior of the features you are going to build is invaluable.

BDD came about because Dan North realized that TDD and really great code meant nothing if it didn't deliver the value or functionality that the stakeholder needed.  This concept was clearly illustrated for me at one organization I worked for when the Development Manager was lamenting about a Product his team was enhancing was pulled from the market because they didn't deliver on time in order for the organization to stay competitive in the market.  He said 'If only they could see all of the cool code that we've written'....To which I said 'Business doesn't care about code they care about delivery" no matter how great your product is from a code perspective it matters not at all if you don't deliver it when your customer needs it.

For those of you who are exploring the use of BDD with your Scrum teams understand that there are essentially two separate efforts that effective teams are working on:

1. Team collaboration - Successful teams using BDD understand that they all need to be involved when building out user story context with Given/When/Then.  In fact I would argue that this is the most important element that drives a clear understanding of what we are building and guidance to when a user story is done.

2. Automation - One of key components of successful Agile teams is the development and maintenance of an effective automation suite.  Utilizing BDD provides an effective way for teams to obtain high levels of automation and do so within the Sprint that they are working in.  A common mistake of newer Agile teams is to develop in one sprint and test in the next and sometimes automate in the third.  Using BDD automation tools such as Cucumber with well written acceptance criteria (I'll provide examples of well written BDD in my next blog post)

A third benefit of BDD is that a Scrum Team builds a clear understanding of the scope of the story.  Since everyone participates in the development of the acceptance criteria, if a scenario is missed, it's a shared miss - No finger pointing, just manage the new scope with a new story and prioritize it in the backlog.

I've helped a number of organizations implement BDD effectively,  one of which did not have any automation at all.  The use of BDD acceptance criteria writing almost immediately improved the understanding of the features being developed and helped my QA team write significantly more test cases than they had been doing.  This effort led to a measurable improvement in Quality even before we added the automation suite later.

Having come from a waterfall world many years ago I can tell you that when you 'get' BDD,  it changes the way that you look at requirements and provides you with a mental framework that you can quickly use to model what is going to be built.

After a few months of using this format at Disney the Product Owners were uniform in their agreement that there simply was no other way that they would want to work with their teams.

Automation IS our goal, but it is not what defines BDD.

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.

Building great products

A long time ago I left college with the notion that I wanted to ultimately run my own business, my job experiences were purposefully diverse, giving me experience in Sales, Banking, Management and ultimately IT and luckily I've been able to do that several times. While I wasn't always engaged in the world of technology during some of its growth, I've always been involved in building and delivering great product.

What I learned during this time is that building great products is much like writing a symphony, you have many instruments that you can choose from for your piece, but if you don't bring them together in the right way, if you don't understand the limitations of those instruments you don't end up with a masterpiece, but rather something that might sound like noise.

I have often used the concept of a symphony as an example for the way that we manage software project delivery.  You have an individual, Conductor, who is responsible for ensuring that everyone in the symphony is playing their parts correctly, are watching the conductor for queues on changes that might be made in the middle of the concert.  When everything comes together correctly you get beautiful music, when it doesn't.....not so nice.  Building software in an Agile world is much like this, the Conductor is the Product Owner and the delivery teams are the musicians who watch the conductor for their queues when small changes are made in the delivery.

Understanding your craft, be it song writing, engineering, sales, etc....is an important element of you becoming great at what you do.  The craft of building great products is being able to master how to manage all of these different crafts in order to bring about something great.  My wife, who is an Arts Manager, has often likened software development as just as much as artists realm as an engineering one.  I have another post I'm writing that explores this in more depth.

For those of us who build a product with software we define our vision, much like a composer will do.  Once the vision is identified then we determine what components (or instruments) we will need to accomplish our vision.

What are the types of instruments that we use build product with software?

1. Product Owners/Managers
2. Product Developers
3. Product Testers
4. Software - Java, .Net, etc...
5. Hardware - Servers, Databases, etc..

What is our endgame with these ingredients?  Build product with software that delivers functionality that customers want and are willing to pay for.  If our instruments aren't aligned with this primary goal, we'll waste time and money and deliver quality that isn't what the customer expected.

When we talk about quality in the software world, we talk about defects, code quality, etc..., however from a holistic standpoint none of this matters if you haven't delivered a product that people want.  Your first goal as a Product Development team is to understand and align yourself to this completely.  If you focus more on delivering technical quality then you aren't delivering the quality that the customer is expecting. Using the example of a restaurant, I can cook and deliver the absolutely best Pasta Primavera to you, but if in fact you wanted a Steak, then I have missed your quality expectations.  It doesn't matter how good the food was, how well it was delivered, it failed to meet your expectations so the entire element of how you perceive the quality of my business is affected.

I think we are moving towards understanding this with concepts such as Personas, however I'll be honest I've been in only one place  where we paid attention to these personas as we built our product,  I think many of our high-tech companies that have evolved over the past 10 years are much more focused on the technical aspects of the product over what the customer wants.  Example?  Facebook, Google.  They release new features and then gauge response and then remove or modify the product features based upon feedback.   I think long-term this is not the paradigm that will bring success to most organizations, eventually you need to be driving your company based upon what your customers want, not what seems cool and technically challenging.

Building great product has absolutely nothing to do with technology.  Technology is merely the enabler of a product that customers want and are willing to pay for.   If we could find a different way to deliver the product without technology (or at least the technology we have in place today) we would do that in a heartbeat.

If we are to re-align our instruments as a technology team delivering quality what would they look like?

1. A clear understanding of what the customer wants, ensuring that whatever we work on is aligned to that need.
2. A clear set of requirements that support that need.  Agile provides a process for capturing user needs with User Stories, however the key miss I see with most user stories is that they aren't written to align to the customer need.
3. A set of software specifications that support the User driven stories.
   1.  What do we mean specifications? Using tools and processes such as TDD and BDD to define the user story at the technical level.  Again another big miss I see with teams who write user stories is their acceptance criteria stays too high level to understand the technical elements we need to delivery as part of our technical quality.
   2. Though Agile is about conversations over documentation, we really can't deliver high quality software unless we build a shared understanding of the user stories and a depth of understanding via specifications.
4. A feedback loop that delivers customer feedback to everything we do.

Notice, in the new set of instruments there is no mention of technology, how you deliver a feature is entirely up to the technologists.  Their responsibility is to deliver customer features, the expectation as professionals is that they will do it with quality.

Delivering great products comes from the intersection of  customer needs and high quality technology.  Great product can survive from lack of technical quality in the short team but it can never survive the lack of focus on features driven by the customer.

Agile Certifications - Why they aren't neccessary

Agile started many years ago with some basic (note I do not say simple) concepts related to how we should work together to build better software products.  Though I struggle with the notion that mere communication among individuals can deliver quality software, it can provide a product that is closer in alignment with the product owner's vision. I remember as Agile unfolded there was a debate on whether we needed things such as certifications.  I recall the argument that the very process of creating certifications for things such as Scrum would defeat the very benefits that the Agile manifesto was attempting to address.

Now many years into the manifesto I have to say that these certifications have brought an element of rigor that 'can' be beneficial but I think often stifle the creativity that can come out of Agile teamwork.  Certifications do not make you a great Scrum Master nor a Product Owner, they merely convey that you have taken a 1-2 day class that has provided you with the  evolved standards that Scrum has been defined to be.

I've been involved in a number of Agile transformations along with working in already high performing agile organizations and none of them are alike.  One thing I have taken  away is that teams who are provided space to try new things often find creative ways to solve the unique challenges they face.

As someone who started in Agile from the project management perspective I quickly realized that I was not your standard project manager who managed against a project plan, happily disconnected from my team.  No I was always learning, asking questions, it is how I went from a project manager into QA, because I took an active role in being in helping my team deliver great software.  Through out it all I was most focused on getting feedback from my team in order to improve our processes.

In those early days there were no certifications, we just took the concepts and did what worked and continued to evaluate how and what we did.  With certifications there is almost a cookie cutter approach to engaging Agile that I don't believe was the intent of the original writers of the manifesto.

Scrum and the processes it provides are extremely important, I'm not saying that these don't bring value.  What I am saying is that you don't need certifications in order to be good at Agile and Scrum.

I always tell my teams, Agile isn't easy, it will highlight every weakness in your delivery process and force you to ask hard questions about how much the organization is committed to changing the way they deliver a product.  Having a Scrum Master or Product Owner certification does not help in these situations.  What does help is working with an experienced Agile coach who has been in the trenches, who is experienced in the demands that Agile and the transformation present.

As an organization looking to adopt Agile, getting certifications for your team is not a requirement to working the concepts that so many teams use to be successful in Agile.  Don't let certifying your team be a precursor to moving toward Agile.  At one organization I worked at we took this approach and ultimately it wasn't necessary as the majority of the people who were 'certified' were not involved in working in daily Scrum team activities.

An experienced coach will be able to guide you through how to work as a team, manage communication and change the way that you deliver software products and your organization.

And yes I have several certifications including CPO and CSM and know that these are now almost standard requirements for anyone wanting to work in an Agile environment However if you are just starting Agile don't assume that someone who has been certified is necessarily an experienced practioner.  When looking for help in adopting Agile you should look for someone who has been involved in more than 5 different Agile implementations or organizations, perspective is worth it's weight in gold.

Product Discovery - Uncover your backlog in Agile

Much of the writing and learning that you gain about Agile focuses on the day to day nuts and bolts part of execution, however I think that teams are missing a much greater opportunity to improve the quality of both execution and delivery if they spent more time developing their backlog. My teams consistently hear me talk about getting contextually rich user stories  as part being able to delivery quickly and with high quality.

In order to get to the point that we have contextually rich user stories teams need to spend some dedicated time building out their product backlog.

Whether you are developing an entirely new product or simply adding features to your existing product, taking the time to fully investigate and build out your User Story backlog is important.

Much is said about doing just enough documentation to get the job done, but what I've seen over the years is that teams that fail to build out user stories that have a specific set of information in them will spend more time trying to figure out what they are doing IN the sprint which negatively impacts quality and the teams velocity.

There is nothing wrong with spending time before a set of sprints building a strong understanding of what the team is going to do.

You wouldn't try to build a house without a certain level of planning ahead of time.  Agile teams often arrive at the start of their Sprints with nothing more than a set of ideas.  If builders showed up at a job site to start building your home with only a rough idea of what you wanted, they couldn't go very quickly nor would they build something of quality that met your needs and expectations.  You might get what you want, but probably not.

Agile teams need to take this approach a bit more, spending time with their Product Managers to not just flush out the features that are wanted, but more importantly the lower level details needed to provide the team an ability to plan more effectively and deliver high quality products.

If a builder shows  up and wanted to pour a basement, they need to know more than that.  They need to know the size of the basement (ie how much concrete do I need) , if the site has been prepared, has drainage been considered, etc.... Building anything of quality requires planning before you can deliver.

Agile I think too often believes that you can go lite on the planning and still delivery quality.  If you think that refactoring is the golden ticket for lack of planning, it's not.  Rarely do teams have time to do the amount of refactoring they require to keep their applications clean and scalable.  This leads to applications that grow in complexity requiring even more time to add features, all the while thinking that we can go lite on planning.

As you consider Agile as a development process, don't forget that Product Discovery is an important element of delivering high quality product quickly.

Agile, Change and the things we can do

We home school our children and a few years ago my wife decided to utilize stories and a Kanban board to manage the kids work flow every day. Doing this provided her the ability to build a backlog of work tasks that our children were going to work on (no we didn't have them perform estimations or commitments :) )  Each day she puts up the work that they need to complete in the Not Started column and then the kids can decide which ones that they want to work on and pull the ticket into the In Progress column.

Once they are done with a ticket my wife reviews the work and if accepted moves the ticket to Accepted.  This approach provided our kids with some level of control over their work flow and also an understanding that they weren't done until Mom signed off on their work.  This way of managing their work provide them visibility to how much is left for the day and more importantly the topics that cause them more trouble.

Now that my daughter is working on her first business/website (she's 13) we are using an Agile Discovery process where we are building a User Story backlog (she's learning VOC) and developing low-fi wireframes (she's learning design) for her website where she will be selling her customized jewelry made out of recycled products, photography of the animals she has seen across the country and raising awareness of animal conservation.  She's now comfortable with an Agile process because we laid the groundwork during school.  I think in many ways teachers could utilize this process which would provide visibility to high performing individuals and those that are struggling.  Taking a page from Scrum perhaps the high performing individuals can provide support to the ones that may be struggling, just like we would expect our Scrum teams to do when someone is struggling with a particularly gnarly code problem.

Agile is most commonly associated with Software Development, but really the iterative continuous improvement concepts apply to anything you want to focus on.

Agile can be applied to changing your habits.  For example if you want to lose weight, write an Epic stating that value of losing weight, then write several thematic user stories with your intermediate goals and then write stories for your sprints with specific activities you need to accomplish (exercise, etc...) put it on the wall for your Kanban tracking.  If necessary have a standup with people who are supporting you so you can report on your progress, impediments (Ben and Jerry's is right next to my office...)

An underlying principle of Agile is the need to change behavior, not just of the teams building your product but those that want them built.  You can't have a smooth running organization if you don't address the intrinsic  behavior of people in general.  Agile can provide the framework for helping make this change by providing a shared language.

When we work in an organization we may think we are all working towards an end goal (ie making great products, making money, etc...) but as soon as an organization begins to grow people who don't know each other and who may have no shared experiences need to start communicating.

I recently completed McCarthy's Core Protocol training  and one of the things I came away from it was that getting people to have a shared framework of communication is the most important thing that high performing teams and organizations should focus on, the rest will come as a result of this effort.  If you deliver this you deliver the ability for these teams to produce great product anywhere/anytime.

Think about it this way - We are all organic systems, who behave based upon the experiences that we take in over our life time.  Since no two humans are organically the same ( not even your own family) we end up with an ineffective communication driven by our life experiences and trained responses.

Core Protocols and in my mind Agile, provide a framework to establish a common language, just as we do with disparate technical systems (isn't that what a service based architecture is all about?), we write code that provides a common communication protocol between them, removing the impediment their different languages pose to having them communication effectively.

As you begin to start to adopt Agile understand that though the practices you read about, such a Release Planning, etc... are extremely important, the need to provide your teams and organizations a shared communication framework are equally important to long-term success.

Sound Agile - Aligning Agile with Soundness

As I indicated in my last post I renamed my blog to Sound Agile and I'll be writing about Agile from the perspective of Soundness and how organizations should be evaluating their Agile adoption. I spent quite a bit of time trying to decide what I wanted to name my consulting business and blog (both are called Sound Agile) and I ultimately wanted to convey what I have seen as successful with respect to the teams and organizations I have worked with over the past 10 years.

Thanks to my wife for providing me a word that when I looked at it provided me with the right context to what I had been trying to convey.

Sound: 

adjective

1. free from injury, damage, defect, disease, etc.; in good condition; healthy; robust: a sound heart; a sound mind.

Supporting Manifesto - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

a. Free from Defect - Speaks to Quality that we strive for in Agile. b. Healthy - Speaks to your employees health and well-being c. Robust - Speaks to building scalable products. d. Sound Mind - Speaks to teams keeping a clear and open mind to improve

2. financially strong, secure, or reliable: a sound business; sound investments.

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

a. Sound business/investment - Speaks to the value proposition that Agile focuses on. b. Financially strong, secure and reliable - Speaks to the ability of Agile teams to delivery products that are foundational to your organizations long term health and security.

3. Competent, sensible, or valid: sound judgment - This speaks to trusting that the people that you are hire are compentent and when following Agile ceremonies such as Standups, Retrospectives and Planning are able to deliver product that is built on solid decisions.

4. Having no defect as to truth, justice, wisdom, or reason: sound advice. - This speaks to the continuous improvement and Retrospectives that drive this effort.

5. Of substantial or enduring character: sound moral values - Speaks to team commitments, believing and supporting themselves, the foundation of Scrum.

We spend so much time writing and talking about things that we should, could, might do to deliver Agile,  We hear people talk about how 'Agile' are you, tell people that doesn't 'Sound Agile' and I think we have muddied the waters of what Agile should be.

When you hear Sound Agile you may be inclined to add an additional adjective 'Sounds Like Agile' and to some degree that is expected.  My focus however will be on the soundness of Agile from the perspective of organizational change an area that isn't really talked about as much as the other elements of day to day Scrum.

I look forward to comments and input to my blog as my writings will form the basis for the types of coaching and consulting I hope to do in the future.

New Blog Name - Sound Agile

As you may have noticed I updated the name on my blog to better reflect where I am going with content and my overall beliefs about what sound Agile practices should be. Sound Agile is derived from the attributes of sound:

sound

1. free from injury, damage, defect, disease, etc.; in good condition; healthy; robust: a sound heart; a sound mind.

2. financially strong, secure, or reliable: a sound business; sound investments.

3. competent, sensible, or valid: sound judgment.

4. having no defect as to truth, justice, wisdom, or reason: sound advice.

5. of substantial or enduring character: sound moral values.

I'll be overlaying my writing on top of Sound to reflect the need I believe to focus on sound judgement over growing process.

You will see my website www.soundagile.com take shape in the next few weeks, please check it out.

Contextually Rich User Stories - The Importance of Details in Small Increments

Every software product that we build begins with a set of requirements. Teams or organizations who have utilized traditional requirements documentation efforts such as Product or Business requirements documents (PRD's or BRD's) typically have issues with translating their requirements process into user stories.  Instead of writing long passages of descriptive requirements that are heavy on the use of 'the user shall' we move to a smaller specification document that convey details to a specific individual feature.

What teams fail to realize is that their old requirements documents weren't all that good at conveying the necessary details that allow teams to delivery their product quickly and with quality.  You see evidence of this lack of clarity with the large number of change requests that are raised during waterfall projects.  In my pre-Agile years it was not uncommon for a typical 6 month project that I led to have over 100 change requests generated to convey the changing nature of the requirements (business, technical and UX).  The Agile manifesto addresses this reality by saying we accept change, why?  Because it's there it will happen, to deny it would be to deny the reality of product development, as we learn more we need to change our approach.

User stories, though small in format, need to have a specific level of detail if a team is to have the ability to accurately estimate and delivery the feature.

The basic User Story:

• Story
• Conversation
• Acceptance Criteria

Can be deceptively simple to those who are just starting

In one organization I worked with as we moved into an Agile process the team looked at the User Story statement  as THE requirement.  It took awhile to get them to learn that successful teams use the User Story format as a specification and not a loose statement with no context associated with it.

An example of a solid User Story specification would look like this:

Another important thing to note with this format is that the team is also collaboratively building Story acceptance criteria by using Behavior Driven Development (BDD) which directly feeds the test automation frameworks that most Agile teams utilize (Cucumber, Fitnesse, to name a few).

There are other efforts/processes that feed into getting the right amount of detail into the story such as Discovery and Pre-Planning and if these are missed you will not obtain the benefits of this format.

Over the past 5 years, teams I have engaged with, who have used this specific format for developing their User Stories have had a much greater success with both delivering on time and more importantly with higher quality.

At my last organization I asked a Scrum team to utilize this process during the Pre-Planning phase of their project.  After the project I learned that the Product Owner had been very worried about the team using precious 'development' time to talk through the work and build out the context of the user stories. After the project was completed he could state without reservation that taking the time to build out contextually rich user stories with the team had produced two key results:

1. The team delivered on time and with more features than he had originally promised the client.
2. When he delivered the demo to the client he had high confidence in the product as it met all of the context that had been build out and there were only 2 minor UI issues that were identified during the 3 iteration project.

Take away - Don't run before you are ready and get the context right before developing.

Rear View Mirrors aka Mater Vision (Retrospective Habits for Agile Teams)

One of my favorite movies is Cars and specifically the character Mater, rusty and crusty but full of humorous and unintended sage advice.

During one point in the movie, Mater starts driving in reverse, on the road, off the road and Lightening McQueen is very impressed and asks Mater how he drives so well and his answer was, Rear View Mirrors to which he adds I don't need to know where I'm going if I already know where I been.

I started thinking about how this applies to high functioning Agile teams and their ability to provide predictability to their organizations.

More specifically I'm talking about how Retrospectives act as our rear view mirrors providing us with key visibility to where we were just at and an opportunity to reflect on where we want to go.

As an Agile team we constantly reflect (via Retrospectives) on where we were just at so that where we are going is incrementally improved, much like Mater and his rear view mirrors.  He's constantly reflecting on where he's been such that he's already where he needs to be before he gets there...

For organizations that are starting to adopt Agile ensuring that your teams utilize the Retrospective process is key to seeing the types of productivity improvements that Agile can and should deliver.

Retrospectives need to be both a no holds barred conversation about what did and did not work, but the team needs to ensure that it's also a safe place in which to talk about the issues that keep us from being really successful.  As a manager or management team you need to back away from the team and give them room to organize themselves.  As I've said before if a team feels empowered and is clear on the vision of the organization they are capable of solving both team and organizational issues that you didn't think were easily solved.

Traits and habits of good Retrospectives are actually very simple:

1. Have it consistently after each iteration.
2. Hold the Retrospective right after your demo while all of the iteration context and issues are fresh in your mind.
3. Each Retrospective should start with review of any action items from the previous sprint.
   1. Scrum Master - Ensure that this happens as this is the key to having the team feel like the issues that are causing problems are actually being addressed.
   2. Scrum Team - You need to commit to addressing the action items identified in a Sprint to ensure that you are applying continuous improvement to your teams processes.
4. Working Agreements - The team needs to have a set of agreements by which their Retrospective will be run, follow these agreements, which should include:
   1. Respect your team members - Allow them to call you out if necessary if you were in fact a blocker (I have been and no it's not nice to hear that, but your teammates are relying on you to make sure that they are successful.)
   2. Attack the problem not the person - This is key, you all want to be successful, don't take things personally, ask questions and come up with solutions that might work.
   3. Understand that not every idea you have will make things better, be prepared to fail.
5. Keep the Retrospective to the members of the Team that are responsible for delivering the work (aka Individual Contributors).  Managers and Stakeholders should not attend.  As a Scrum Master you may have to tactfully address this if these individuals want to attend.
6. Relax, we aren't trying to solve world peace.

Continuous Improvement leads to predictable velocity providing you with the ability to be like Mater.

"At the end of the day, I'm being paid to write code."

"At the end of the day, I'm being paid to write code.".

Technology isn't important, Product is

We are so enamored with technology today, what it can do, the excitement it brings to us as technologists that we have lost sight of the fact that technology isn't the end game for a business. Why?  Because if your organization could figure out a way to run their business so that it wasn't dependent upon technology they would do it in a heartbeat.   The people who own and run businesses don't care about the underlying technology, even those who classify themselves as technology companies.  At the end of the day technology enables the business to develop product.  They aren't in the business of  developing technology as  end product and I think that goes for companies who deliver 'technical' products.

Many teams I've worked on in the past 10 years have isolated themselves from the organization, instead telling stakeholders they were  focusing on technical excellence.  Leaving the stakeholders wondering why they weren't delivering what they wanted all in the name of technical excellence.

I worked on one project that was so late that the business ending up exiting the market that they were in.  In response the Development manager said if only the stakeholders knew how cool the technology was that they had worked on they would change their mind.  Really?  They could care less, all they wanted was a product that would keep them in the market and making money.

Though the amount of information we can process has exploded we aren't really solving really new problems, they are just much larger in scale and are required with much higher availability.  At the end of the day business runs on information that drives product decisions that build value.  Like any other part of the organization we are responsible for delivering value, not technology.

If we could deliver data to our business without all of this cool technology like hadoop, etc....they would be just as satisfied.

We should spend much more time on how we can deliver what we need for the business with less over building systems that continually build in complexity because we aren't product focused.  Think about it, organizations that deliver at scale, such as car manufacturers continue to refine their processes so that complexity is removed, whereas we seem to have to add complexity in order to deliver value.  They add technology where it makes sense not just because it's the latest thing.

Technology isn't important but our technical product is.  We have architects, tech leads, dev managers, however I don't often see them actually defining the technical product that the business needs, rather they evaluate specific pieces of it, SQL server over Oracle, Java over .Net, etc.....and with each iteration individual personalities can influence the type of technology being implemented, often times in direct competition with the documented tech stack that company operates in.

What we end up with is a technology product that doesn't scale well and adds cost to the organization in both resources and revenue delays.  When confronted with the mess we've made we tell the organization that can solve the problem with a new platform.  Unfortunately we often fail to fully deliver on that promise for the same reasons that we got into the situation in the first place.

This is not to say that we don't try to build systems right. Executives also need to bear responsibility for not providing the Engineers you have hired the support and time necessary to actually build technical products that deliver value to your business product, they are one and the same in today's world.

When your technical team is forced to meet dates, the inherent compromises that need to be made typically result in short cuts to your technical product in order to deliver the most for your business product.  You can do this in the short term, but if you don't provide your teams time to shore up these short cuts your technical debt continues to grow.  And like any debt you eventually have to pay it.  Pay it at the end of every release like a credit card you won't incur finance charges.  Continue to pay just the minimum and you eventually can go bankrupt.

Agile and the Management Impact

You're a technology manager in an organization that has decided that they are going to adopt Agile.  Thunk......now what? You've spent years becoming the high performing manager you are today, managing the day-to-day details of your team, holding things together, making decisions big and small....You are the leader, success of your team hinges on your ability to make decisions that impact the way the team works. Your team is successful because of your management efforts....Sound like you?

This Agile thing is telling me that my teams are now going to be 'self-organizing' and be able to make decisions on their own...what the heck am I going to do?

Managers who are asked to move their organization to Agile may often believe like they are providing the path to the doorway out of the company.  This resistance can be one of the primary impediments to successful Agile adoption and as an organization Sr. Management needs to be aware of this paradigm and provide support to middle managers that Agile is not about replacing them but truly about getting them into a position where they are focused in the truly valuable parts of their job - Strategic Planning, Employee Development..the bigger picture.

Stephen Covey teaches that successful managers are the ones who are able to remove themselves from the quadrant of activities that are Urgent and Important and focus on the activities that were Important but Not Urgent, meaning remove yourself from day-to-day decision-making over planning and strategy development.

So many of us can get sucked into the day-to-day minutiae of our teams that we end up ignoring the bigger picture areas which should be our focus.  Why?  Because dealing with Important and Urgent activities is an addictive feeling, you feel like you are making important decisions when in fact your team is probably more than capable of making them without you.

Agile provides your team with leadership opportunities that aren't found in more traditional process control organizations.  Step back and let your team grow.  I've been amazed how teams, when given the opportunity, can solve process issues and impediments to productivity that I would have never thought of.  The collective minds of your organization are capable of great things.

As a manager you need and want to embrace this power and provide support for you team.  Let them help you and help the organization deliver on the promise that Agile provides.

How can you help?

• Understand that for your teams to succeed they need to fail, yes I said that.
• Don't attend their ceremonies (standups, retrospectives)  Why?  The team needs to be able to speak openly and honestly about what is working and not working without you being present.
• Use the working metrics available to you, velocity, burndown.  If your team says they are going to do 'x' story points and they do that consistently, what else do you need to know?
• Don't force your opinions on what they 'SHOULD' be doing.  Have confidence that you have hired great people and they like you want to succeed.
• Work closely with the Product Owner and Scrum Master to discuss any concerns you have.  Understand why things are working a certain way before leveling your judgement.
• Don't act as a Scrum Master or Product Owner of the team. Why?  You manage their careers and it's highly unlikely that the team will receive the benefits of iterative continuous improvement if they don't feel confident that they can say when things aren't working well.
• Don't believe that everything is great the way it is, anything can be improved.

Agile will provide transparency with respect to the areas of your organization that isn't working efficiently.  As a management team you will need to focus your attention on addressing these impediments as your Agile teams mature.  If these hurdles and impediments aren't dealt with you will reach a ceiling on the ROI that Agile can provide.  As with your teams, management needs to be honest with themselves about broader organizational issues so that a stronger and more effective organization emerges.

Agile isn't just about delivering software faster, it's much more than that.  Understanding that will make the transition your Agile smoother.

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.