Agile Transformation – Coaching needs and requirements

Having been involved in Agile for over 10 years, and for most of these years I have  helped organizations switch to Agile, I have (I believe) a great grasp of what needs to happen when your organization decides to ‘Go Agile’.

Yes the larger the organization the more that the organizational change element is brought in to the mix, and for this post I want to focus on the elements of Agile coaching as it relates to these larger transformation efforts, which with SAFe is a hot area of growth for Agile consulting.

With the large Agile transformations I’ve been involved with I have identified what I believe are the three main types of coaches you are likely to come across in an Agile transformation:

  1. Those that have had experience in the trenches, who have led Scrum teams, built the products that are delivered to the business.
  2. Those that have primarily been involved with Agile ‘transformations’ at the management level.
  3. Those that have taken the necessary courses to ‘become’ Agile and may have been  a Project Manager in another life. (I’m not denigrating PM’s as I was a PM who first experienced Agile from this perspective, I’m rather saying that there are coaches who haven’t actually been involved with Agile, but have gone out and obtained Agile certifications, making them ‘look’ like people who have the right ‘credentials’ when people who don’t know Agile are looking to hire coaches)

Let’s talk about what each one brings to the table and what you need to look for when bringing on a coach to support your specific Agile transformation.

  1. Coaches from the Trenches
    1. Key Benefits- These individuals bring a wealth of experience with how to operationalize Agile. They get it, they believe in it and they now what works, how to make course corrections when something isn’t working AND they have huge levels of creditability with technical teams.  They talk the talk and can walk the walk.
    2. Key Weaknesses – If there is one the weakness with this type of coach is that in larger scaled Agile transformations, there are very specific processes and formats that get rolled out to the entire organization so that everyone is doing the same thing.  Sounds right doesn’t it?  This individual will want to work out what works for their team and not always align to the Transformation processes, causing frustration between the coach and the group leading the transformation.
    3. Things to think about - Agile is not like making cars where every production line making car X has to be doing the same thing so that you maximize the speed of the process and build in your quality and productivity INTO the process.  Agile isn’t like that, rather Agile is a framework that should allow for each Scrum team the flexibility to determine WHAT works for them without being prescriptive.
      1. My Input When I am helping an organization move to Agile I like ‘sprinkle’ the framework and tenants of Agile to the teams and then let the teams iterate on the process that works for them.  I give them the things I look for to determine how they are doing, such as stable velocity, good backlog and effective and accurate estimation (which of course feeds the stable velocity).  The ‘from the Trenches’ individual is one who will succeed very will in this type of environment and not very well in an extremely structured Agile process.
  2. Coaches who were Managers – These individuals have typically seen their organization have success with Agile and have made the decision to move into an Agile career.
    1. Key Benefits – As with the from the Trenches coach, this individual does ‘get it’ and has an ability to gain creditability with upper management and can convey the higher level benefits to them.  This individual talks the talk of management and understands how to get in the head of management to help them understand their responsibilities in helping a transformation succeed.
    2. Key Weaknesses - So far I see way more of these individuals as coaches than I do the in the trenches coaches.  This can cause issues because they can sometimes tend to take a more hands off approach in working with their teams and don’t have the experience nor creditability to work with the technical teams in a direct manner.  They simply don’t have the technical and Agile chops to help the team grow and aren’t as adept and making course corrections to the process.  Here you are seeing the effects of Top down driven Agile over bottom up (which I’m more a proponent of).
    3. Things to Think about – Consider having these types of coaches run more of the program level coaching, working more closely with upper management to help them mature in their thinking and protect the teams as they figure out how to be successful in their Agile processes.
  3. Certification Coaches – As I indicated these are the people who have been involved with software development for many years, perhaps in the project management career path and have taken Certified Scrum Master classes and maybe Certified Product Owner.  Though they understand ‘software development’ they don’t, IMHO, understand Product Development and all that this implies in an Agile world.
    1. Key Benefits – Of the three types of coaches, these individuals probably offer the least from a benefits perspective if expected to lead an Agile transformation effort.  These types of individuals understand the basics of Agile and run teams from that perspective.  Not having worked in the trenches they haven’t yet had the opportunity to deal with real world Agile and the challenges it presents.  This is not to say that these individuals don’t have the skills, knowledge or capabilities to be great coaches but what I am saying is that if you have a large number of coaches fall into this group then your PD teams will be at a disadvantage and this individual will struggle to gain creditability with their Scrum teams and your Agile adoption will fail.
    2. Key Weaknessess – As stated above, these coaches tend to not yet have the creditability or depth of knowledge to be as effective as coaching types 1 and 2, they will need to be partnered with more experienced coaches to enable them to be successful and grown their Agile skills.
    3. Things to Think about - Look for people who can demonstrate servant leadership in their past experience, this is a key behavior of successful PM’s, Tech Leads and Managers.  I believe my success in Agile is primarily due to the fact that I am a servant leader by nature.

When you go looking for coaches consider your organizations size, current development maturity and honest assessment of the problems you face with your current Product Delivery processes.  And I do mean HONEST, if you can’t take honesty then Agile is not for you.  The Continuous Improvement element of Agile demands honesty and if you are an organization that doesn’t want to hear that you PD teams have issues then you will continue to have a less efficient model of delivering value to your customers (and isn’t that what ALL of this is really about?)

These will provide you insight into what you will need to move towards Agile.

Also try to avoid labeling your coaches when they come in such as that one is our BDD expert, that one is our blah blah expert. This will tend to keep other coaches from participating and sharing their skills for a specific area and ensure that you processes for that specific area of expertise will suffer ( I speak from experience on this one ).

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 to 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 transformative process and one that if you as an organization buy 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 the 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 on 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?