Agile Planning – I have a need a need for speed

Working at Disney a number of years ago was in so many ways transformative for me (not sure why I left) because it provided me with an opportunity to work with an organization that needed to get better at delivering software for our partners and we ended up choosing Agile as our path.

Disney was the place where I had the opportunity to help build an Agile process from Requirements to Delivery and what we discovered was that we needed to develop an effective planning process that allowed us to build a solid backlog of work before we just started coding.  I here that so often in organizations that are just starting to adopt Agile.  I think a statement I heard recently is descriptive of organizations that just start coding – Shoot and Point.

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

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

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

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

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

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

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

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

Agile – The Ugly Truth

If you are an organization that is considering moving to Agile, especially a larger one there is an Ugly Truth that Agile consulting firms don’t want you know:

You don’t need coaches to come in full-time to help you on your journey……

Sure you can spend a ton of money on people who will come in and tell you how you should be doing standup, scrum, retrospectives, etc….Try to get everyone to do the same thing across your organization.  The Truth? In successful Agile organizations everyone can be different, that’s ok.  Yes you want some consistency but doing things by rote doesn’t get you where you want to go.

In the coaching world we talk about organizations Doing Agile who never get to Being Agile.  What’s the difference??  Everything.

Yes the basics of Agile include things such as standup, retros, sprint planning and release planning, but those are the basics that can make you feel like you are Agile, but that’s about it.

Agile IS a transformative process and one that if you as an organization by into, will receive great value from in the form of valued delivered in a more consistent manner.

I remember years ago when I was managing a technical project that required that I purchase some hardware and though I had found a better deal with a different vendor my boss told me to buy IBM hardware (at a much higher price) with the advice – ‘You don’t get fired for buying IBM’.

I think that many large organizations fall into this mindset and when trying to move to Agile  They fall into the mistaken belief that if you hire one of the large Agile coaching groups or hire Agile consultants that you will ensure success or at the very least not get fired because you hired ‘Agile professionals’.

Yes you do need people who can provide support in the important areas that Agile truly needs to have in order to bring the value you desire from it:

  1. Automation – Develop, implement and improve your test automation frameworks.  This includes unit, integration and functional areas.  You MUST make this investment and you need to get to high levels of automation, because without it you cannot go fast, time for testing will hold you back.
  2. Planning and Estimation – An area that is very much overlooked when moving your product development teams to Agile is the need for these teams to form a strong working relationship and learn how to plan in estimate in Agile.  The notion, especially for larger organizations, that you don’t need to do some level of up front planning is a sure way to fail and fast.
  3. Organizational change – Probably more than anything you need to understand that your organization will change, significantly in many ways, when you move to Agile.  You need to prepare your managers to let go and let their teams own their deliverables (trust me if you give this to people they will own it).  You as an organization need to understand that your management group will change, you will need fewer managers (sorry folks that is a reality).  Though in reality many of your current managers were placed in these roles as more as a retention means over a true management track that the organization has defined.  These people need to move into your Tech Lead roles, they run their scrum teams, own the technical and architectural elements of their product code.  Managers will oversee several Scrum Teams and will be focused on larger concepts such as technical roadmaps, cross organizational planning and staff development.

So the Ugly Truth is that you don’t need to spend hundreds of thousands of dollars on coaches who will tell your teams what to do.  Instead hire people who have been on the ground, who can help your teams learn the skills they need such as TDD, BDD, User Story Mapping and Estimating.

Start small and grow the process into the organization.  You need to get your processes working in a small-scale and then move outwards into the organization.  The people who are successful in your pilot groups become your sales people for the next groups.  Trust me, I listen to the people who actually do the work more than I ever do people who try to provide me basic information that I can find anywhere online.

 

The Myth of Rockstars – Teams Deliver Not Individuals

Over the years I’ve had the opportunity to work with numerous software development teams in both large and small organizations many of whom have a singular focus of hiring technical rock stars.

Though it sounds like something we should all aspire to, I think that we often lose sight of how great a team is when everyone works together over the individual rock star mentality

Point in case the 2014 Chicago Bulls.  They yet again lost their rock star (Derrick Rose) due to injury and the team could have just thrown in the towel, but they didn’t.  They weren’t considered ‘rock stars’ by how people in the NBA view talent , but they had something that rock stars don’t always have, commitment to the team.  A selfless focus on what they had to do to win a game in the NBA and for several months they had the best record in the NBA from January through March.

Another Bulls analogy would be the championship Bulls of the 1990’s.  Until Coach Jackson was able to get Michael Jordan to work as a team member and not be the rock star that he obviously was, the Bulls didn’t win a championship.  Only when Michael began to work within the team structure were the Bulls able to win six championships.

The point here is that rock stars often can’t/don’t deliver for a team, rather they achieve greatness within the context of themselves.  Many technical rock stars are singularly focused on achieving technical dominance based upon this mythical rock star status we give to them.  This leads all to often to these individuals climbing into leadership roles for which they have no real skills to succeed with.

Teams that deliver understand that we all must sacrifice something of ourselves for the betterment of the team.  Rock stars don’t see it that way and those that never see it that way are destined to be winners to themselves and not to a greater good.

Sports unfortunately is often the best analogy to teams and in Agile our Scrum concepts come from a team formation from Rugby, so perhaps the sports analogies are appropriate in most cases when talking about technical teams that deliver.

Agile is all about delivery, and fast.  But with speed comes the need for discipline, multiple disciplines in a Scrum team.  Everyone, and I mean everyone, has to pitch in.  If you are a Java developer and you have legacy C++ code, guess what??  You need to learn from C++ so that when time is tight and the delivery important you can step in and help out.  That’s teamwork, no rock star needed, just a willingness to put yourself out for your team.  If you are a developer and there needs to be testing in order to close out the Sprint, guess what?? You need to test.  It’s amazing what you will learn when you test your own code from another perspective.

When I’m hiring I look for people who have had broad level of experiences.  People who have done just one thing but are considered a Rock Star for it, aren’t really my interest.  Great products and high quality come from those with well rounded backgrounds, who see the edges as places that we need to explore.

Great teams have that, broad level’s of experience.

So when you are thinking about building a team remember that an organization, any part of it, is a sum of the total parts, not just the rock stars.

 

 

 

Security and Compliance in Agile

It’s been awhile since I last posted anything but that’s because I’ve been knee-deep in helping a Security and Compliance team move from a traditional waterfall approach to an Agile approach to developing and managing their work.

Talk to any development group in a large organization, especially one that is Agile, and say the words Governance or Compliance (or worse Audit) and you will get a collective shudder and the sound of everyone running for the door.

The truth is this: Every organization has to protect their customers and their brand.  We do this in many different ways, but one thing that we don’t do well typically is ensuring that our Product Development teams actually know what these groups do and the value that they can bring in knowledge to developers.  We often view developers as people who know everything, hell they can code to make features come to life so they must also know about secure coding practices and the like (guess what, they don’t)

Security Governance and Compliance shouldn’t be considered necessary evils, rather they should be considered insurance policies that we take out every time we push code to production.  You wouldn’t think about driving a car without insurance because if you do hit someone and injure them, it will cost you a boat load of money.  Yes the odds may be small but taking that risk is one that most people won’t take.  We should look at our Security and Governance in the same light, in fact an even brighter light because very few drivers are out there actually trying to hit you to hurt you, whereas hackers are doing just that to your site day in and day out.

With the speed at which hackers and attackers are figuring out new ways to breach our security protocols Security and Compliance teams need to work in a much faster pace.  Think incremental improvements over gold plating a solution.

In Agile teams are focused on delivering value to the business every two weeks and as they go through their process of iterative design and development we also focus on technical excellence.  Product Development teams need to be able to get fast feedback on security questions so that they can incorporate Security changes before development begins.  As a Product Owner you have to understand that the velocity of your team to deliver value MUST include time for them to refactor code and implement ever better secure code, it’s simply not up for negotiation if you want a high quality secure product that your customers engage in.

The teams that I’m working with have been willing to engage and somewhat leery in moving to Agile and we are tackling how to handle a team that doesn’t deliver code and whose work doesn’t necessarily fit into a strict 2 week timeframe.  Additionally these teams aren’t used to thinking in short increments so breaking down their work doesn’t come naturally, but they are finding ways to do it and they seem to like the visibility and transparency Agile provides.

For Story estimation I developed a quick and easy way for them to estimate their work, taking into account that we don’t have true Scrum teams but loosely aligned people working on distinctly disparate tracks of work, it looks like this:

  1. 13 points – One person working one Story for the entire sprint.  This would typically fall into the same category as a Research spike.
  2. 8 points – One person working one story for half of the sprint
  3. 1-5 points – One person working one story for 1, 2, 3 or 4 days.

Some of the team has started to use this and we are starting to see what our potential team velocity might be.  This will help us next year when we do our Roadmap planning.

Additionally since we are using Rally, I’ve created six-week release windows that teams can align their work to and then assign the iteration that they will complete the work.  With both the Release and Iteration views I can see what the team is planning and what they are executing.

Perhaps the biggest challenge that we need to address next is how do we build a plan for work that may span 1-3 years in duration.  The team has commented several times that moving to Agile is hard since they are used to doing everything in a Waterfall method yet the reality is that whether we are doing Agile or Waterfall as a Program Manager I would expect them to identify high level milestones, understand and describe how the project will unfold.  None of this can’t be done in Agile.

The notion that Agile isn’t about planning has always amused me since I know that in Agile if you are doing it right it is all about PLANNING.  One thing that differentiates Agile from Waterfall from a Project Management perspective is that we don’t have a change management process.  I think we have believed that laying out a project in a Gantt chart with tons of up front planning that really results in Change Requests was effective.  Instead identify the key milestones that make up the project, commit to those and then understand that we’ll change along the way but the key business value that we are delivering shouldn’t.  If it does then you aren’t working on the right stuff.

To those Information Security Management groups who think that they can’t be ‘Agile’, think again.

 

 

 

 

 

Agile Metrics

One of the hardest things that we struggle with in Agile is with is how to report how we are doing with respect to our projects.  Agile or otherwise we still primarily think of our software development in a project orientation.

All of our historical metrics from our waterfall days talk about headcount, resourcing, man hours (days), project milestones, etc…..

In Agile we don’t produce the type of metrics that management has historically used as progress tools.

You hear quite often that in Agile velocity is king (kind of like cash) and in a real sense that is true for me.

Velocity represents the amount of value that a single Scrum team can deliver.  We know that each Scrum team has a specific set fixed cost and the value that they ‘consistently’ deliver reflects a key metric for management to key on.

  • Velocity – What can you glean from a single number?
    • Effective Estimation – A Scrum team that doesn’t deliver accurate or confident estimates they will see their velocity roller coaster from sprint to sprint.
      • What to look for? –
        • If a team consistently has to move a story to the next sprint because it couldn’t be completed that is an indicator for estimation improvement.  This has the effect of reducing the points for that sprint as they can’t accept an incomplete story.
        • If a team consistently has large stories entering their sprint, ie larger than 8 points, this is an indication that they haven’t decomposed their stories enough.  Lack of story breakdown results in more unknowns leading to inaccurate sprint commitments.
  • Planned vs Actual – Another flavor of identifying estimation issues.
    • What to track? – Once a team develops a consistent velocity (usually takes 3-5 sprints) then that is what we should expect each iteration, providing people aren’t on vacation, etc…A team that commits to varying levels of story points each sprint typically hasn’t performed enough story development or they lack a well-groomed backlog.
    • Burndown – I specifically like this as it reflects the above issues very nicely.
      • What to look for? – Pretty simple really.  A team that has performed effective story decomposition, planning and estimation should expect to see their work being delivered and completed throughout the entire sprint.
      • What to look for? – Teams who have a cliff dive burndown where all of the story points in development hit QA at the end of the sprint.  (Solution? – QA needs to set up a working agreement so that they will only test ‘x’ number of points in any given day.  If the team delivers 12 points on Friday and the agreement is 8 points for testing, then 4 story points will not get accepted, regardless if ‘development is done’ (cold uh?).
    • Sprint changes – Though harder to track with most of the tools out there (Rally has an app but I’m not sure it provides information that is easily derived regarding which stories actually left the sprint and which ones came in).  Regardless of how you track it, this one metric will tell you a lot about an organization and it’s overall planning effectiveness.  Remember – Agile accepts that change is inevitable, but in the real world you can’t have unmanaged change, teams can’t work effectively or productively in that manner.
    • Sprint Plan vs Actual – As teams improve in their planning and estimation skills, they should also get better at providing accurate estimates as to the number of Sprints it will take to complete a feature (aka project).  One of the things I had a VP say to me recently is that he wasn’t sure Agile was the way because at the end of the day he still had to make commitments to Sr. Mgt.  The notion that Agile can’t provide plans that have accuracy is wrong, however you  but need to focus on Discovery, Planning and Estimation efforts.  And we need to understand that there are places and times where we need to take time to do this work.  Thinking that we should always just be coding is a sure way to build something, but probably not the right something.

Succeeding to Fail in Agile

In an Agile environment everyone needs to understand that ‘being Agile’ is about taking the framework of tools, processes and methodologies and applying them to your specific organizational needs.

At Disney where I was part of a group that moved into Agile, our first foray into Agile Discovery and Planning was, well an epic fail. We we didn’t produce any work product that would allow us to enter a Sprint.  We developed a lot of ‘stuff’ but as it was at is it turned out, not the ‘right’ stuff.

But from that initial failure we evaluated what did work (group Discovery) and what didn’t (PO not taking ownership of story development).  From there we were able to begin to understand the ‘what’ that was important and over the course of around six months we developed a pretty solid delivery model that allowed the organization to feel confident in our delivery abilities.

Now, what worked for us at Disney more than likely won’t work for your organization.  The only way to find out is to try something, anything and see how it goes.

If you want to be a virtuosos at any musical instrument you need to practice, hour upon hour of repetition.  Along this long road of preparation you will find some efforts easy, others hard.  You will fail at mastering some part of a technique that just seems so difficult, you feel you will never get past that point and then you will try something else and BAM, you got it.

From our failures comes learning, the type of learning that becomes part of your DNA. Your mind takes over and can put thinking in the background as you play your instrument.

To be great in Agile, your organization has to change its very DNA.  If you want to succeed, you have to fail and you have to fail often and quickly.

You hear that a lot in Agile when we are talking about our test automation, let it fail early and often. We know that fixing issues while still in development is significantly cheaper than fixing them in Production.

Make sure you instill in your organization, management support for succeeding to fail.

Baseball players get into the Hall of Fame for succeeding to fail at a 70% clip, if you bat over .300 for your career you have a good chance of making it to Cooperstown.

As your teams embark on their Agile journey, keep these concepts in mind to ensure you are driving towards success:

  • Self-organization – We want this to happen and for teams to be empowered, because they know more than anyone, what the real pain points are to their daily work.  Let them try something to see if it works no matter how crazy you may think it sounds.
  • Retrospectives – Make sure that a team that is self organized and is empowered to try new approaches is having regular post Sprint retrospectives.  This continuous inspect and adapt cycle ensures that we are always evaluating what works and what doesn’t.

In the end if things aren’t working – TRY SOMETHING. What do you have to lose?

Investment Portfolio Management Applied to Product Management

I’ve been telling myself that I needed to attempt to apply formal investment portfolio management techniques to how we value, prioritize and manage our portfolio of product development efforts, so here goes (definitely still a work in progress)
Back in 1950’s Dr. Harry Markowitz created an investment model called the ‘Efficient Portfolio’.  Markowitz stipulated with his theory that an “Efficient Portfolio is one where no added diversification can lower the portfolio’s risk for a given return expectation (alternately, no additional expected return can be gained without increasing the risk of the portfolio)”.
The Markowitz Efficient Frontier is the set of all portfolios that will give the highest expected return for each given level of risk.
 
This model set the framework for how current money managers build a portfolio of securities that provide range of investment returns to meet each investors risk profile.  Providing investors with a broad range of risk/return choices allows individual investors to build an investment portfolio that meets their specific risk threshold with respect to a given rate of return.
An efficient portfolio looks like this:
 Efficient Frontier
When you are younger and have time to take chances your risk/return profile might be higher on the frontier, whereas at retirement you will slide down that scale as you are more interested in protecting your total investment.  One thing to note is that if your risk/return data falls above the efficient frontier, then you are accepting a level of risk that is not in line with the rate of return you might receive.  Pushing past the efficient frontier can open you up to unexpectedly high returns but conversely you can also expect very high negative returns due to the risk you are taking on.
Product Development organizations can utilize the Frontier as well, for example, a young startup will have a much higher appetite for risk as they understand that to take market share from competitors they need to take risks with speed to market.  However there are specific elements of risk that need to be considered as you speed your product to market.  Ensuring that Usability has been considered, Prototypes have been developed, code quality is considered and test automation all need to play part when you are building your risk/return Efficient Frontier for your Product Portfolio.
If we were to apply the Efficient Frontier to how we manage our Software Development investments we could build a risk/return profile that is easy to understand and align with the organizations risk/return profile.   There are many software projects that at inception are known to be risky, however a lack of empirical data often means that the projects will get the green light and then fail miserably.  The organizations inability to accurately asses risk/return at any time with their software development investments is a huge blind spot and keeps us from consistently delivering the value that the organization needs to stay competitive.
Agile addresses the value (return) part of what the Efficient Frontier speaks to however it talks nothing of Risk overtly.  Risk is more implied with the notion that we manage it by delivering in short increments and focus on shipping value consistently.  However Risk is more quantifiable as I mentioned earlier.
Building an Efficient Frontier in the investment world is a data intensive effort, which our current product/software development processes doesn’t easily support.  However I believe that we can use the formula that Markowitz created to generate an Efficient Frontier for Product and Software Development organizations.
For this effort we will make some assumptions with respect to the Frontier model and changes to Markowitz’s formula so that it works with our limited data set:
  1. Portfolio = Product Development
    1. An organization can have several Products in their Portfolio –
      1. Consumer Facing
      2. Internal Facing
      3. Infrastructure
      4. Research and Development
  2. A security is equivalent to a Scrum Team.
    1. These would equate to the individual securities that Markowitz speaks to in his model.  Where an investment portfolio consists of many securities, each with their own risk/return profiles so to does an organizations product development portfolio consist of the same.  Each team is a security that can on its own provide return that comes with an associated risk.
    2. Though we don’t think of investment securities as having dependencies (as software development teams have) in fact a diversified investment portfolio consists of a range of investments that will perform a certain way based upon the dependency that business has to the market that they operate in, so in this case the notion of a portfolio still holds as a viable means to build a Product Development Efficient Frontier.
  3. Potential Risk Parameters:
    1. Development Lifecycle – Waterfall, Agile, RUP, XP, Blended (use at macro level). You could equate this potentially to Bonds, Stocks or other investment instruments.
    2. Experience of Team
    3. Number of Scrum Teams
    4. % Test Automation
    5. Code Complexity
    6. Speed to Market
    7. Roadmap volatility

In my next post I’ll provide some supporting ways we can ‘build’ an efficient frontier for Agile Product Portfolio analysis that both Product and Program Managers can utilize to assess priorities for the entire organizational backlog.