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

250px-MaterCars 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.

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

article-1255763-08965ee6000005dc-57_468x286.jpg

article-1255763-08965EE6000005DC-57_468x286 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......

Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out