Top Down or Bottom Up - Large Scale Agile Adoption

So I've worked in both large and small organizations where we have gone through an Agile adoption or the phrase of the day, Transformation. Having seen both sides of the coin I started realizing that you have two paths to take when considering moving your organization to an Agile delivery methodology.

I use the phrase delivery, because I think at the end of the day that is what we are talking about.  Strip away the manifesto's goals of conversation over documentation, accepting change, etc...What are are really talking about is moving an organization from a Project delivery methodology to one that is Product delivery oriented.

What is the difference?  From a Management perspective actually quite large.

1. Project Delivery - These have very strong controls which move people to a new project.  Budgets are set up for the specific time period of the project and then up front requirements and design are completed in order to ensure that the project is fully ready to be engaged.  Project Managers manage all facets of the project via extensive project planning and plans.  Management receives up dates as to the project progress on a regular schedule, usually weekly. Resources are assigned either in full or in part, yet no one actually monitors nor can they really manage whether or not someone is working 25% on a particular project.  Projects tend to focus on reporting and there is high pressure to ensure that individual projects are green, which drives teams to deliver on the easiest and often less valuable parts of the project first and only at the end of the project is the hard work tackled, which reveals itself as budget overruns or timeline delays (or worse delivery of reduced scope).  Project reporting is elaborate and management receives project reports that are often sanitized.  Value is typically not delivered to the organization until the end of the project.
2. Product Delivery - The work that is done for a Product is centered around a value stream it delivers and the work is ongoing.  Teams are funded as a whole and are kept together long-term in order to maximize their productivity.  Work is planned out in short increments called Release Plans that span anywhere from 6-12 weeks, with 2 week sprints.  Management receives regular updates (2 weeks) but can access information radiators at anytime, transparency is the key and goal with Agile Product Delivery.  Teams commit to work in 2 week sprints and their commitment is key to building trust with Management.  As time goes by management can trust that both a teams abilities and productivity can be counted on.  Teams are focused on delivering high quality code to production every two weeks which brings value to the organizations investment in them along with the increased value in terms of new sales, reduced costs, etc...Feedback loops via Product Demonstrations provides management the ability to assess where they are going with the product and deliver not what was asked for up front (Project Delivery) but rather what is actually needed (Product Delivery).

So what does the difference between Project and Product delivery approaches have to do with Agile adoption, well everything.

Most Agile adoptions begin at the bottom of the organization with the teams tasked with developing new software.  These efforts are borne, as the Agile manifesto was, out of frustration with how software was being developed in their respective organizations.  Often management is aware of the issues these teams face but are unable or unwilling to make any changes to how things are currently working and why would they?  You learn very early in your career that rocking the boat is not something that goes over well with organizations, my first boss told me I couldn't by computers that weren't from IBM because you don't get fired if you buy IBM. The message is that if anything goes wrong you need to point to well-known names, processes, etc.. with which to blame or use as support.  To think that this doesn't go on today is to place your head in the proverbial sand.

Though we can have great success with bottom up Agile adoptions with respect to improved productivity within small groups/teams, the overall Project oriented organization is typically still in place.  Management still wants to see project plans, have things 'planned' out for up to an entire year, they aren't comfortable with the fuzzy feel of product roadmaps.  They want commitments, even false ones, so that when things fail they can point to the fact that they had all of their planning in place.

For Agile to really take hold, Sr. Leaders need to change the way that they manage both their people and the work.  It starts first I think in understanding that we have not learned how to speak to management very well yet from an Agile/Scrum perspective.

We need to understand what management is really concerned about and then center our product delivery efforts around that.  One of the problems that we face with some of our leaders is that they themselves don't always know what to be focused on, they are looking at multiple balls in the air but at the end of the day as a Sr. Leader I think I have just a few things I should be focused on:

1. Growth - This is often related to sales, market and revenue.
2. Profits - Tightly aligned with the first item, our ability to make a consistent profit is what helps us continue to reinvest in our company.  Ever increasing revenue or sales without corresponding profits will eventually lead a company into bankruptcy, money isn't free and it is not endlessly available, in spite of what we think we see with new technology organizations.
3. Organizational Excellence - Because none of the above can happen unless you have a great organization.

Agile actually addresses all of the above, yet we spend more time talking about how we will improve our individual work efforts which causes us to  fail to tie this to the needs of management.  Management on the other hand often views the improvements that come from the bottom up approach as more of an anomaly rather than an organizational improvement worth adopting.

Trust is the missing component when it comes to conveying how Agile will make the entire organization better.

Agile isn't easy and it requires skills that frankly many of our Sr. Leaders lack or don't fully utilize and the politics of most organizations reward behavior that doesn't align with Agile principles such as transparency, open honest conversation and openly questioning the status quo.  We have people in power who got there by way of the non-Agile status quo and changing that means they have to learn how the new game is played in order to stay on top, it's much easier to keep things they way they are over learning how to navigate the new.

So how do we speak to our Sr. Leaders with respect to Agile?

1. Better ROI - Talk to any Finance executive about what they look at when purchasing a piece of equipment that will deliver revenue and you will hear them talk about Net Present Value of the investment, Positive Cash Flow and Depreciation costs.
   1. We improve ROI in Agile due to our focus on only the most valuable items.  In non-Agile project work often are working on features/functionality that may be important to someone inside the organization yet will bring little or no value to the organization.
   2. When we are able to start talking about the value streams of our organization, be they revenue, cost reduction or improving our brand image we begin to be able to have a better ROI conversation with management.
   3. We also positively impact ROI via higher levels of productivity gained with dedicated teams.
2. Flexibility - One of the most important elements that 21st century organizations require is the ability to be flexible enough to react to market forces or reactions.  Financing large projects far out into the future with the expectation of some level of return and no we don't really have great track records of predicting future ROI out very far into the future.  With Agile we provide the framework to identify the most valuable work for the business in small planning windows.
   1. Sr. Management needs to understand that this flexibility comes with an obligation to have consistent short term review windows as the team progresses so that we deliver what is actually needed and not what we thought we wanted.  You may have thought you needed a Ferrari when in fact what you needed was a mini-van, we provide the framework to course correct via Sprint reviews every two weeks.  If you plan all of your project up front for the Ferrari, we'll certainly try to make that happen, but in reality as the end of the project nears you will probably get the car but with a lawnmower engine and no brakes, it may look like a Ferrari but it won't operate like one nor will it provide the value the organization really needed.
3. Predictability - Another key element that we deliver with Agile is predictability and accountability.  Your teams will be much more accurate in planning and delivering in short-term 2 week sprints with a planning horizon of 6-8 weeks.  What management needs to look for is consistent delivery of the committed work that the team makes, commitment is everything.  What Wall Street analysts look for is a business that can provide a solid ROI, react responsibly to their competitors or even better be a market leaders and provide predictable results year in and year out.

So the question at hand is what is better a Top Down or Bottom Up adoption?  My money for long-term success is on the organization that can consume what Agile really means, not just to their development teams but the organization as a whole.  You can't BE Agile if you don't make the paradigm shift from command and control to one of collaborative and collective delivery.

Agile isn't Easy

Over the years I have seen many teams and organizations who start on their journey towards Agile product delivery make the mistake of thinking that Agile is easy, promotes freely changing direction and worse will fix all of your issues and make everything better quickly and easily.  The truth couldn't be further from the reality. There is no such thing as a perfect software development delivery process.  Unlike production lines for things such as automobiles where you have the same pieces going to together each and every time and each piece has a specific functionality, tolerance and timing, software development is the exact opposite.

Software development is about meeting changing needs across the dynamic nature of business  For example - You wouldn't see an automobile company add anew feature to a car on their assembly line over a 2-4 week time period.  They need time to design the entire process and ensure that the production line is capable of accepting the new change.

Traditional software development tends to align a bit more to the automobile example and in fact there are times where this type of rigid, pragmatic approach to product delivery is actually the correct process (Agile isn't for everyone nor for every situation).

However for those that are going to move to Agile you need understand that the type of discipline that you might use in the automobile example actually needs to exist in your Agile processes, seriously you ask? Yes - You need to be able to deliver high quality, well-tested and fully functional pieces of software every two weeks. Now are you seeing how difficult Agile can be?

If you think Agile is easy, then you are already on the path to failure and unmet expectations.

It is very common for teams who are moving to Agile to take their interpretation of the Agile Manifesto to the unhealthy extremes, for example:

• Working Software Over Comprehensive Documentation

Many teams I've worked with take this to mean NO documentation and that couldn't be further from the truth.  We value working software over the need for documentation but I've never believed that you can have long-term success with your product without delivering some levels of documentation.  Without documentation your software knowledge becomes tribal and when your tribe leaves the team or your organization, well so does their knowledge.

There are way for teams to build documentation as part of their daily Sprint development work.  Using the combination of user stories and Behavior Driven Development (BDD) acceptance criteria as the foundational elements of your work you are creating your documentation as part of the work needed to deliver quickly.  The great value in BDD is that the acceptance criteria is written in English syntax and then translated into test automation.

This process of writing stories with BDD is supported by Gojko Adzics book, Specification by Example and allows us to deliver light weight documentation during our sprints.  I often see teams adding a story to a future sprint to handle their 'documentation' requirements of their previous work but I haven't seen this work long-term.  Functional development, dealing with bugs, etc... will ultimately push these stories down into the backlog, never to be seen again.

The process described above is not easy, but it can be done and the teams that can get to this level of capability will succeed in driving value to your organization every two weeks.

One of the things that I consistently tell organizations moving to Agile is that it will highlight every current weakness of your product/software delivery methods.  Agile is a game changer, it requires a mind shift in how you look at your product, the work that supports it and how you see the visualize the value your product delivers.  If you are a leader who is going to be uncomfortable finding out truths about your organizations inefficient manner of product delivery then you need to think twice about moving to Agile.

Do you have TITL (To Important to Lose) people in your organization?  If you do, then you need to really look at how they influence any changes in your organization.  Do you need to get their approval, gain their support, etc....?  If so you will find more often than not that Agile will scare the hell out of them.  Successful Agile teams/organizations understand that self organizing teams take away the need for many of the day-to-day management decisions our middle management layer makes.  Agile speed comes when you remove the friction of management layers and provide teams with a clear vision of what you want them to deliver.

You must be prepared for the resistance that you will face from your product delivery teams, not everyone wants to go to Agile  We become comfortable with what we know and do in our daily work life and in that comfort comes stasis.  If you are not prepared to lose people, especially your TITL people, then you need to question if Agile is really for you.

I know it sounds heartless, but I've been working for over 30 years and one of the first things I learned right out of college was that technology was disruptive and if you weren't on board with how it changes how you work you would be left behind. At one company I worked for many years ago, I saw Regional sales managers who had been with the company for over 30 years and when we rolled out a sales force tracking/marketing tool (which I led) there were several who refused to even turn on the computer, they were all let go within months.  As employees we have the obligation to continue to grow and learn and continue to make ourselves valuable to our organization and if we don't, then you as a leader have an obligation to make tough decisions that ensure that the organization is continuing to grow and not stagnate with old processes.  It's not personal it's business.

As you move to Agile you also need to understand the investment that needs to be made in your technology stack.  Many organizations have decades old technology stacks which have been shoe horned into the future and though you get by you won't be able to become Agile until you have a strong Continuous Integration framework, high levels of Unit, Integration and Functional test automation.  Getting to this will take time (and using the stories and BDD disciplines mentioned above will help you get there).  You simply can't go fast if you don't have the technology backbone that supports it.

Agile isn't easy by any stretch of the imagination, it requires thoughtful introspection, focus on continuous improvement, disciplined delivery and a tenacity for value and quality that is never satisfied.

Baking In Quality with Agile

One of the things that I love about Agile and especially the related techniques of BDD and Test Automation is that if done correctly your teams are essentially baking Quality into your products AS they develop, not after. Traditional SDLC (read waterfall) took a very linear approach to project delivery which in turn translated into a similar approach to how we developed and delivered our software products.

In our traditional delivery methods, quality was not 'baked' in but tested out and we never ever got to the point where we are able to test out all of the 'defects' that are found, instead we create a bug database where 'bugs' go to die.  Every organization typically has some form of a bug database with bugs that were 'found' sometimes years ago and were never fixed (of course begging the question were they ever bugs in the first place?)  In Agile we really don't want to see a bug database because we should be instilling a zero defect policy for each sprint, meaning that we should never be introducing new tech debt into our product.

As I progressed on my Agile journey I came to realize that there are actually two types of 'bugs' that we encounter when we develop software:

1. Bugs as Missed or Undefined Requirements
2. Bugs as True Bugs

-- Bugs as Missed or Undefined Requirements - I will argue (and in a book that I am starting to write about this topic) that a majority of the bugs that we find and document aren't really bugs at all, but rather functionality that has been misinterpreted based upon the requirements definition that comes out of segregated development processes, ie Write Requirements, Develop Software, Test Software and Deploy Software.

Language is such an imprecise way of communicating that it almost virtually guarantees that if you have more than 1 person developing the software for your product you will get different interpretations of how to implement the requirement functionally.

Remember the old 'The System Shall' statement? that is commonly used in writing Business Requirements documents?  I always thought that this missed the scope of the requirement, what about what the System Shall Not Do?.  We focus so much on happy path for our functional development that we miss large segments of functionality based upon what an application shouldn't be allowed to do.

Let's take an example of an English word to convey what I'm meaning:

What do you think of when you see the word - BASS

Do you think of this:

OR this?

These have the same spelling in the English language yet they have two entirely different meanings. Our life experiences become a prism for how we interpret what we read and how we react to it. (PS, I'm a musician so I think of the instrument before the fish)

Teams that rely on written requirements documents that are reviewed and worked on independently, meaning developers develop the code/functionality and then pass it on to testers will inherently have issues/bugs related to how something was interpreted and then developed.  In the above example the developers may have thought they were delivering a bass guitar, but the testers were expecting a bass fish (yeah extreme I know) but I believe this is the root of many of our issues when trying to deliver what the business expected in the first place.

-- Bugs as True Bugs - I believe that true bugs are more technical than functional (or should be).  Bugs related to how integration happens are very common because although we can describe the behavior of our feature we can't always anticipate issues related to how independent systems will work together.  Many 'true' bugs in Agile are caught in the moment and fixed before they ever make their way to production.  For the Finance people out there this is a tremendous cost saving that has been proven time and again.  ROI is greatly enhanced when you deal with tech debt up front rather over time.  And please don't ever think really that it is more important to get 'something' to production over making sure that the product is operationally sound.

So what to do?

To address the  inherent limitations with our  communication, we need to abstract our thinking into more concrete descriptions of behavior over broad-based statements such as the System Shall.

User Stories and the corresponding BDD acceptance criteria are a great way to do this as a BDD example table clearly defines the behavior of our product functionality via outcome based upon inputs.  The 'language' of BDD is unique so that everyone can begin to have a shared understanding of what the story and behavior of the product(aka system) will do.  BDD abstracts our communication and removes individual interpretation.

In Agile we start by ensuring that the teams understand that they OWN the quality of their delivery. One of the things that I absolutely love about high performing Agile team is that there is no finger-pointing, if a Sprint fails to deliver what the team committed to then everyone shares the blame, not just an individual or functional group.

How we bake quality into our products is by understanding how to write User Stories that provide context without the ability to misinterpret the meaning of the requirements.

To do this we must first ensure that we have a well written user story, what does that look like?

A good user story needs to identify the What and then the Value statement.  Many teams that I have worked with start to write stories that only identify the actor and What but leave out the value statement, which is really the proof that what we are working on is of sufficient value to devote our resources to.  A good user story should never have any Creative or Technical design conveyed, I know that many people like to show their technical knowledge by writing stories that convey what they think the design or system will need to utilize, but all that does is start the team down a path before exploring all options.

Behavior over language interpretation is what you are striving for when writing contextually rich user stories.

BDD with its accompanied Example statements takes an otherwise basic user story and brings it to life.  Much like we do when we take basic ingredients for cookies and then bring them together in the right amounts to deliver awesomeness every time.

Software quality is much like baking, you need:

• The right ingredients - Good individual team members, honest communication, commitment to quality
• The right process - Write good user stories, add quality BDD acceptance criteria, code and test in parallel and then deliver, involve the entire team in writing BDD, involve the entire team in the estimation process.

By taking the time to build contextually rich user stories and define the story with BDD acceptance you move towards a shared understanding of the 'behavior of your product' over one that is driven by functional requirements.  Requirements tend to convey to little of behavior and focus more on the big win that is being conveyed to Sr. Management regarding what is being delivered.

Agile is a very disciplined delivery process and in order to bake the quality into your product you need to develop efficient processes that keep the User Story/BDD train running smoothly.  If you are entering a sprint and then writing your BDD then you are already behind, you need to develop a process by which teams are working on current sprint development AND building context for the next one.  It can be done and when it is you get what I call progressive regression with the automation that comes out of your BDD work.

Agile is very disciplined and to think that going Agile will make your current life easier, well guess again.  What Agile will do is highlight EVERY current weakness you have in your current product delivery process and then focus your attention on finding ways of improving on them.

For those of you looking for workshops regarding User Story/BDD techniques, please reach out to me at soundagile@gmail.com.

Software Engineering is Not Engineering (More Like Art)

Recently I had an interesting conversation regarding whether or not software developers were engineers or not. The most compelling argument that they could provide for why Software Engineering was truly an Engineering discipline centered around the fact that Universities and Colleges have their Computer Science group in the Engineering department.  That is not sufficient in my mind to by default call Software Engineers well, Engineers. Why? Consider the following

Engineers who build skyscrapers, airplanes, bridges and products that require low tolerance for defects are often operating under the laws of science and as such require that they account for many scientific elements when building their products.

They perform a great amount of 'testing' both in theory and with product before something is released for use.  Their engineering practices are based upon scientific principles that go through extensive peer review and have been building in knowledge for hundreds if not thousands of years.

Now lets look at the definition of Engineering:

1. The branch of science and technology concerned with the design, building, and use of engines, machines, and structures.
2. The work done by, or the occupation of, an engineer.
3. (Business / Professions) the profession of applying scientific principles to the design, construction, and maintenance of engines, cars, machines, etc. (mechanical engineering), buildings, bridges, roads, etc. (civil engineering), electrical machines and communication systems (electrical engineering), chemical plant and machinery (chemical engineering), or aircraft (aeronautical engineering)

Though of this I think can be applied to the science of computers, ie the hardware = Machines I don't however see much if any of this being applied to Software Development.

A paper in 1996 (William Aspray, Reinhard Keil-Slawik, David L. Parnas) talks about some of the reasons that writing code isn't associated with Engineering:

"Computer science is often characterized as an engineering discipline with the systematic study and development of software as its principal subject matter. Software Engineering, however,although combining both key words, has not become a central discipline in most computer science departments.  In many respects, this discipline embodies the same ideosyncracies that can be observed within computer science as a whole such as:

• Highly innovative and rapidly changing field with no broadly recognised core of material that every practitioner must know; • Few results are supported by empirical or comparative studies; • Work within the field older than 3–4 years is rarely acknowledged or referenced; • Old problems are given new names and old solutions overlooked; • Evolution of the discipline is tightly coupled to economic and societal demands; • There is a need for interdisciplinary work comprising e.g. mathematics, psychology, business or management science, … ; • Continuing debate about whether there should be a discipline called software engineering, and if so, whether this should be treated as another discipline among the set of traditional engineering disciplines."

As you read through this I think we can start to see a clear delineation between the disciplines required of 'Engineering' and the disciplines that Software Development requires (Note - This is not an article to criticize people who write software, but rather a way for us to better understand how to manage them and how to help them deliver even better software)

Go to almost any software development team and you will find a mix of people who have ended up going down the path of writing software, they can be people who were Computer Science majors all the way over to people with a Liberal Arts degrees.

The languages that allow us to write software today have matured over the years and as such have become easier to learn and work with.   This mix of skills and backgrounds is not bad, but it deviates from what an Engineering team building an airplane might look like.  Full transparency here, I have never worked in an organization that does true Engineering, but I know many people who do, and I suspect that you would not find people who are designing/engineering bridges or airplanes who don't have a strong educational background in Engineering, but you will find these people in your software development teams.

So why is 'Software Engineering' more art than science?

I think that Software Development is more art than science because we must create software that we interact with on a more human basis.  Creativity abounds in web development as we continue to strive to bring intuitive and easy to use interfaces to the people who are our 'users'.  The people who write software must be able to synthesize multiple layers of code, from Front End to Back end and everything in between. This talent is probably more aligned to writing a symphony in that you have to deal with an entire array of players, each with different instruments (API, Legacy, etc..) and when you get it right you get beautiful music, when you get it wrong you get noise.

When writing software we have the option to try multiple paths to an end, whereas when building a bridge our ability to deviate from proven engineering practices success is much more limiting and catastrophic when we do when we don't.

One can also argue that the newer languages being created are designed to make writing software more accessible to more and more people who have not be through a computer science programs, we are striving to get our languages to ever more English like syntax.

Consider also that people who write software are not held to specific engineering practices.  Software, as it has evolved, has provided people who 'develop' software product with endless ways to implement it the underlying code.  The fact that there are not any set standards that every Software Engineer must use I think clearly shows that software is not a true engineering discipline, but rather a creative one.  Artists embellish, they innovate, the push boundaries into new ways of performing....I think this better describes many of our software developers more than engineering.

The beauty of current software development is that you have the ability to envision new ways of implementing code that delivers functionality and in doing so create new coding processes that others can use.  Software languages provide many different ways to write code to deliver a product functionality, that might be 3 lines of code or it could be 100, it depends on the background and experience of the individual writing the code.

I think when we start thinking about how to manage and support our Product Development teams in our organizations we would benefit from providing them the framework that encourages high quality through innovation, failing fast, and supports both the individual and groups ability to determine their success.  That is not to say that Sr. Leadership doesn't play a part here, it certainly does, by providing clear vision of what is wanted (think of a symphony conductor, who must bring out greatness while providing their interpretation of a particular piece), an ability to accept failure as part of success and a fearless ability to have confidence that when you provide the other two components people will bring greatness as a by-product.

Artists operate in a very Agile manner, we listen and feed off of each other and in the process discover new ways to approach our art. Listen to jazz music and you see the elements of Agile and creativity evident as the small group (Scrum team) takes a song and through listening to each other can create new music, sounds or approaches to an old song.

As with Artists, Engineers don't like to be told something can't be done, that quest to make something happen that has never existed before is what an artist strives for, there is an emotional rush that comes with artistic creation and I think the same is true of software product creation.

Engineers who build skyscrapers, bridges and planes are no less artistic or innovative in their designs however they must take a much more rigorous approach to what they deliver, they simply don't have the ability to go back and redo it.  If they get it wrong people die, though there is of course software that is also mission critical, but for the vast majority of us who develop software for a living, we are able to take a less rigorous approach when we create our products and we expect in Agile to move to a continuous delivery model so our work is never 'done'.

Delivery Management vs Project Management

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

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

What is the difference?

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

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

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

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

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

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

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

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

Agile 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 - 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 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.

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.