Management and Agile - To Succeed or Not to Succeed

As more and more larger organizations look to Agile as a means of delivering software to their customers the one thing that keeps coming back to me is that for any of this to work there has to be transparency and acceptance that a move to Agile will change your organization, not understanding this will court almost inevitable failure. Agile in itself is an aspirational desire to change the way that we deliver software, one that does away with the project processes that evolved over the years from Waterfall.  I know that waterfall feels sound and safe with all of its up front business analysis, project planning, Steering Committees and that all important Change Management process, but in reality it really is more of a facade than foundation.

Having managed work and projects in both worlds I have seen how it all works.  Recently I was told (in an Agile organization) that Project Managers are responsible for delivery and it was at that point that my thoughts crystallized around my own journey, Project Managers don't deliver, Teams do.

At it's heart Agile is about everyone doing their part to make our product delivery better, whatever that looks like for your organization in that moment in time.  Agile by itself is not prescriptive, the Scrum/Lean techniques and processes that have evolved from our Agile journey may be a bit more prescriptive and become more so when we add things like Scrum certifications to people's palmares.  We need remember that one of the key reasons that the manifesto came into being was an intense desire to find better ways to deliver software, which means the journey has no end and certifications and such are merely ways for us to have a shared language.  Let me repeat, once you commence on your Agile 'journey' it doesn't have an end, you will always be evaluating what you can do better.

So back to the question at hand, to succeed or not to succeed in Agile, what needs to happen?

1. Trust - First and foremost we need to begin to build trust between Sr. Management and our Product Delivery teams.  If we have a history of delivering late, with fewer features and cost overruns it is really hard for that same management team to flip the switch once you say you are Agile and trust the very teams who haven't delivered in the past.  Trust is a two-way street and the great thing about Agile is that once you begin to master the techniques and methods that successful teams utilize trust is almost a by-product of that.
   1. Commitments - In Waterfall we are making a 'commitment' to deliver a set of value/features in a specified period of time based upon a business requirements document as guidance for what the business/customer is asking for.  When we make a commitment farther out into the future we become less and less accurate with our plans, it is the nature of the unknown unknowns in life.  Things change, they always do, so to expect that our business and software development teams, in today's ever-changing world, can predict 9-12 months in the future exactly what they are going to deliver is simply living in delusion.  Manage reality or it will manage you.  Commitments in Agile are much shorter in time, basically every 2 weeks.  These commitments however are based upon the Vision that YOU management need to provide.  You say you can't plan for the future every two weeks I would argue you can't plan much further out.  By planning and committing in shorter delivery increments, management get an opportunity to change direction without causing massive pain from already planned out work.  We need to be able to change direction or refocus efforts on the things that are most valuable to our business, not what we made big plans for last year that we thought we needed.  Locking in feature development that doesn't meet customer needs, simply wastes money and loses market share.  When teams make and keep their commitments to you, they gain confidence and you gain trust.
      1.  Context - In most waterfall projects we end up asking for absolutely everything we think we might need, when in reality sometimes 70% of what we asked for (or even less) is more than enough to meet the needs we were trying to address.  Focus on the most Valuable things your customer wants and move on to the next highest value work, not diminishing returns on things customers may not value as much as we might.  Teams want to work on what brings the most value to the organization, development teams when provided the transparency of why we need to do something can do amazing things.
   2. Self Organizing Teams - This one really causes I think the most concern for management.  You in essence are saying that the teams that you currently manage are better able to make decisions about how to delivery our products.  Guess what, they are.  These are people who work in the trenches every single day, know every single issue, impediment, risk, etc... associated with your current product delivery processes.  And every one of them has probably said something to the effect of, 'If I was in charge I'd to do X to fix this'.  I've been a Sr. Manager for many years and have built several high performing teams and one of the best things I can do for them is to provide guidance and vision for what I'm looking for and letting them solve the issues that deliver the solution.  I'm a smart guy but I don't have all of the answers and if you are the type of manager who believes that in order to be 'respected' you have to be the one to manage how Agile will change your product delivery processes you will fail personally and the organization will suffer as a whole.  Teams of people can solve major problems much more easily than one person can, so let them have the ability to self organize and empower them with making the necessary changes to improve your product delivery.
      1. Context - With great power comes great responsibility.  By ceding some level of daily control to your teams you are also doing so with the expectation that they deliver on what they commit to..  If they don't then they must provide a game plan based upon the Retrospective on how they will solve their inability to hit their commitments.
2. Investment - Agile won't come without an investment cost associated with it.  If like many large organizations you have a mess of legacy code mixed with attempts at migrating to newer technology stacks, business requirements and rules imbedded in code with tribal knowledge scattered through the organization.  Agile requires speed in your product development processes which translates into several investment areas:
   1. Automation - When we say automate we mean across the entire spectrum of the organization, if it can be automated you should probably evaluate whether it can/should be.  More specifically we want to automate:
      1. Unit Tests - Developers should be writing unit tests for everything they build, preferably using XP techniques such as TDD (Test Driven Development).  These are not really hard processes but if you are starting from scratch there is both discipline and framework that needs to be built-in order to get to a mature state for test automation.  Unit tests need to be executed with every build, because with that comes fast feedback if something broke, fix it early and you increase speed and profitability.
      2. Integration Tests - Probably one of the harder areas to get high levels of automation in, primarily because the organization hasn't invested in the appropriate product like test environments.  Be prepared in your Agile journey to spend heavily on getting the right environments in place and highly available.  Testing the performance of your system right before you deliver is a recipe for disaster and delays (remember time is money).
      3. Functional Tests - These are the tests management is probably most familiar with and may even have reviewed at one point or another.  These are typically the manual tests that QA will execute at the end of your waterfall project, where we are not baking in Quality but testing out defects.  Building high levels of automated testing at the functional level gets to what I call, Progressive Regression.  Instead of running a final full regression at the end of a 6-9 month project, why not do it every single night?  You will need to again invest in physical environments but also in people training as many in the QA world are not equipped to handle the new role of a Software Engineer in Test.
         1. Word of Caution - Don't rely only on Test Automation in your functional testing efforts, you still need real people with hands on testing capabilities because at the end of the day automated testing cannot always tell you when something is bad from an experience or product flow perspective.
      4. Deployments - One of the hardest things that teams fail at is planning for deployments to their environments.  Making your deployment process as frictionless as possible is a high value target for your organization.  Many organizations don't have a fully functional DevOps org and many in this field are still struggling to figure out how to operate in an Agile world.  Let them figure it out and provide them with the tools that will support automation of critical deployment processes and hold them accountable to doing it.  To many times we purchase tools and then never make the time to actually use them, invest and utilize, that is the key to your ROI.
      5. None of the above work comes without an investment in both hardware and people.  Current requirements processes will change substantially as you move to an Agile cadence.  People will struggle to find their way, some level of productivity reduction is expected in the beginning of an Agile transformation. You as a Leader need to set a clear vision of why the organization needs to change, make it clear that the teams have accountability to deliver the work that they commit to and that you as a leader have accountability to provide them with space to learn, fail and finally improve.  Successful Agile includes failure because without it we aren't really learning from our mistakes, rather hiding the truth.  Agile done right makes everything visible, especially who is accountable for what.
3. Patience - Nothing great was ever built-in a day or a week.  Odds are good that this will take more time than you thought it would, but also make it clear to the organization that an Agile death march is not something that you are taking on either.  Agile is about accountability and commitment, use these values to your benefit and identify those that simply can't or won't work in an Agile environment.

From a management perspective you need to understand your role in the success of any Agile transformation, it must also change the way you look at and manage your business.

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.

You Know You Aren't Agile If

Thought I'd start off the new year and take a page from Jeff Foxworthy and use is famous tag line for Agile. Though intended to bring some humor to the question it really is something that every organization typically asks themselves. Please add more :)

You know your not Agile if:

• Your Product Owner drops by once in awhile to yell at the team for not giving them what they wanted
• Your Product Owner is entirely responsible for writing User Stories
• Your Development and QA teams are separate groups
• Your teams treat missed commitments like a Hollywood marriage
• Your team writes user stories in the current Sprint
• A daily Scrum looks like a bunch of stoners standing around
• Your product backlog changes more than Kim Kardashian changes her cloths.
• You think MVP was Kevin Durant last year
• You think BDD is something you do in the privacy of your own home

We spend a lot of time talking about what Agile looks like, should be etc... but at the end of the day Agile is about addressing the issues that keep you from being great and dealing with them in a manner which focuses on the what not the who.

There is no finger pointing in Agile (just like there is no crying in baseball).

Finding out what stops you from succeeding is a fundamental element of achieving greatness at anything.

You know your not Agile if you are asking yourself if you are or not.

GSD or Feeling Good about the Wrong Things

Over the past couple of years I have heard the term GSD used quite a bit as a means to describe high-performing individuals (note I did not say team). I have to admit that this is not an acronym that I was very familiar with, primarily GSD referred to my designation in college as someone who didn't want to join a fraternity, the politically correct term would be Gosh Darn Independent (And this is probably a great way to define who I have been throughout my career).

Before embarking on this post I did some quick google searches and came up with some thoughts on GSD:

1. The Urban Dictionary definition:
   1. GSD is brought about through severe bout of procrastination, not getting work done on a regular basis, therefore needing to set aside long amounts of time to disappear and get shit done.
2. What Spinks Thinks - http://whatspinksthinks.com/2013/11/04/get-shit-done-the-worst-startup-culture-ever/

The term, as it is used now is, Get Shit Done, which does sound great at first pass.  However when you start working with GSD as part of building a defined delivery process you start to see some very ugly things drop out of it:

• Heros - Those great people who came in and saved the day and got some serious shit done under intense pressure.  Never mind that the day they were saving maybe shouldn't have happened in the first place or even worse, the situation requiring them to save the day via GSD was of their own making, convienently lost in the thrill of GSD.
• Lack of Defined work - Who cares what I am doing so long as at the end of the day I can show you how much shit I got done.
• Lack of Plans - See above.

The problem as I see it with GSD is that we aren't asking ourselves a basic question - Are we doing the right shit at the right time?

Yes getting 'shit' done is good and getting it in done makes us feel good, however if there is no real process behind your way of getting shit done then you will be destined for unpredictable delivery of the work that brings your organization the most value.

I find in my experience that GSD is more about individual glory over a team (see my blog on Teams Deliver) which I find troubling on so many levels.

Organizations spend lot's of money having their technology teams deliver features that they believe bring value to the business and even though there may be many ways of delivering this value, ie Agile, Waterfall, Lean, I have yet to see GSD making its way into main stream product and project management lexicon.

Continuing my educational tour of the world of GSD I found a posting from two guys named Daniel Epstein and Pascal Finnette who appear to be individuals who provide support, coaching and services to technology entrepreneurs specifically regarding GSD:

1. GYSHIDO - A movement started a few years ago dedicated to The Art of Getting Your Shit Done.  They identified that their most intrinsic value as employees was that they got shit done, but in looking at their code of honor I see elements of good process, so is it possible thatGSD has some value?  Too soon to tell.  But here is their code of honor:
   1. Relentless focus - Focus on the 10% of your activities which drive most of the value. Relentlessly.
   2. Boring consistency - Do the right things over and over again. Consistency forms habits. Habits make hard things effortless.
   3. No Bullshit - Don't bullshit yourself or others. Apply brutal honesty and transparency to everything you do.
   4. No Meetings - Meetings come in only two forms: Standing or social. If it's social, it's over breakfast, lunch, coffee, dinner or drinks. If not - don't sit down.
   5. Follow up - Don't let others wait for your part of the job. Ever.
   6. Don't be an Asshole

As I read through their ethics I believe (I haven't talked with these guys) that their process could align with the agile type world.  Why?

• Many of the elements of what they believe is good GDS is what I consider good behavior of Agile teams:
  • Focus on the work that delivers the most value - Agile, 2 week sprints, deliver production ready features continually.
  • Consistency - Keep your Scrum Teams together, let them improve in estimation, execution, test automation, boring?  maybe, get shit done fast?  yes
  • No Bullshit - Retrospectives ask us to be brutally honest when things are working and fix what doesn't work.  Attack the problem not the person (see number 6 - Don't be an Asshole)
  • Follow-up - In Agile I always talk about how we need to think of minutes over hours when resolving issues that are blocking us from completing our work.

Agile teams focus on identifying the valuable 'thing' that we need to deliver and then develop lightweight plans to deliver it incrementally. I suspect that GSD has its roots in waterfall SDLC where a project would roll happily along, green week after week, oblivious or ignorant to how the project was actually unfolding.  Decisions made by the team that never surfaced had large impacts on scope and viability of the project.

GSD I believe emanates from the need for a project team to 'pull a rabbit' out of the hat in order to deliver the project 'on-time'.  My years as a waterfall PM saw this time and time again.  We fool ourselves into thinking that we can predict a large project from beginning to end all up front, you can't, period.

So when you are rewarded in a GSD organization they are ultimately is saying that the organization values chaos over effective planning and delivery.

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?

Investment Portfolio Management Applied to Product Management

I've been telling myself that I needed to attempt to apply formal investment portfolio management techniques to how we value, prioritize and manage our portfolio of product development efforts, so here goes (definitely still a work in progress)

Back in 1950's Dr. Harry Markowitz created an investment model called the 'Efficient Portfolio'.  Markowitz stipulated with his theory that an "Efficient Portfolio is one where no added diversification can lower the portfolio's risk for a given return expectation (alternately, no additional expected return can be gained without increasing the risk of the portfolio)".

The Markowitz Efficient Frontier is the set of all portfolios that will give the highest expected return for each given level of risk.

 

This model set the framework for how current money managers build a portfolio of securities that provide range of investment returns to meet each investors risk profile.  Providing investors with a broad range of risk/return choices allows individual investors to build an investment portfolio that meets their specific risk threshold with respect to a given rate of return.

An efficient portfolio looks like this:

 

When you are younger and have time to take chances your risk/return profile might be higher on the frontier, whereas at retirement you will slide down that scale as you are more interested in protecting your total investment.  One thing to note is that if your risk/return data falls above the efficient frontier, then you are accepting a level of risk that is not in line with the rate of return you might receive.  Pushing past the efficient frontier can open you up to unexpectedly high returns but conversely you can also expect very high negative returns due to the risk you are taking on.

Product Development organizations can utilize the Frontier as well, for example, a young startup will have a much higher appetite for risk as they understand that to take market share from competitors they need to take risks with speed to market.  However there are specific elements of risk that need to be considered as you speed your product to market.  Ensuring that Usability has been considered, Prototypes have been developed, code quality is considered and test automation all need to play part when you are building your risk/return Efficient Frontier for your Product Portfolio.

If we were to apply the Efficient Frontier to how we manage our Software Development investments we could build a risk/return profile that is easy to understand and align with the organizations risk/return profile.   There are many software projects that at inception are known to be risky, however a lack of empirical data often means that the projects will get the green light and then fail miserably.  The organizations inability to accurately asses risk/return at any time with their software development investments is a huge blind spot and keeps us from consistently delivering the value that the organization needs to stay competitive.

Agile addresses the value (return) part of what the Efficient Frontier speaks to however it talks nothing of Risk overtly.  Risk is more implied with the notion that we manage it by delivering in short increments and focus on shipping value consistently.  However Risk is more quantifiable as I mentioned earlier.

Building an Efficient Frontier in the investment world is a data intensive effort, which our current product/software development processes doesn't easily support.  However I believe that we can use the formula that Markowitz created to generate an Efficient Frontier for Product and Software Development organizations.

For this effort we will make some assumptions with respect to the Frontier model and changes to Markowitz's formula so that it works with our limited data set:

1. Portfolio = Product Development
   1. An organization can have several Products in their Portfolio -
      1. Consumer Facing
      2. Internal Facing
      3. Infrastructure
      4. Research and Development
2. A security is equivalent to a Scrum Team.
   1. These would equate to the individual securities that Markowitz speaks to in his model.  Where an investment portfolio consists of many securities, each with their own risk/return profiles so to does an organizations product development portfolio consist of the same.  Each team is a security that can on its own provide return that comes with an associated risk.
   2. Though we don't think of investment securities as having dependencies (as software development teams have) in fact a diversified investment portfolio consists of a range of investments that will perform a certain way based upon the dependency that business has to the market that they operate in, so in this case the notion of a portfolio still holds as a viable means to build a Product Development Efficient Frontier.
3. Potential Risk Parameters:
   1. Development Lifecycle - Waterfall, Agile, RUP, XP, Blended (use at macro level). You could equate this potentially to Bonds, Stocks or other investment instruments.
   2. Experience of Team
   3. Number of Scrum Teams
   4. % Test Automation
   5. Code Complexity
   6. Speed to Market
   7. Roadmap volatility

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

Monetizing Agile Projects

Coming from a finance background my education and experience is grounded in ensuring that money invested returns ROI.  We think of things such as ROI, IRR Cash Flow, etc... For example when a manufacturing company decides to make a hardware purchase for machinery (any kind) to produce some type of 'goods/product' they perform financial analysis regarding the cost of the equipment, the rate of return that it will generate, how quickly they can amortize it and ultimately what is the net profit that the machine is expected to generate over its anticipated lifespan.

For most of my career we start on projects that have a goal in mind, potentially new revenue or cost savings, some have gone so far as to try to determine the ROI, but in general I haven't seen the type of due diligence that manufacturing type companies perform, applied universally to software development.

This may be an underlying cause of many of the software development projects never seeing the light of day or failing to deliver the expected outcome because we never performed effective financial plans that would establish the scope and speed necessary to deliver a software product so that it warrants the investment.

In Agile I think we have ways of providing some level of financial analysis that can provide us with an understanding if an idea is worth pursuing.

1. Using the following as a guideline we can begin to estimate costs:
   1. Team Size - 5
   2. Blended Rate - $125 an hour
   3. Hourly team rate - $625
   4. Cost of Sprint(2 weeks) - $50,000
2. Let's assume that the feature that we want the team to work on has come back with an estimate of 5 Sprints.
   1. Estimated Development Cost - $250,000
3. Let's now assume that this investment is expected to yield an additional $1,000,000 in annual revenue.
4. Expected ROI in the first year - 300%

Before we engage our teams we need to be sure that the $250k investment will return an appropriate level of return.   In this simple example its a no brainer.

But our world of software development isn't always so clear-cut, we often don't know what the expected outcome will be until we release the product into the wild.  There is often additional cost for refactoring before the product hits the mark with your consumers.

But using some of these simple ways of working through anticipated costs we can easily modify the example to reflect additional Sprints for refactoring once the product is released.

In this example let's assume that the team requires an additional 8 sprints to move from MVP to final product.

The final cost of the product would climb to $625k and our return would drop significantly to 54%.  Still not bad but not the eye-popping number we initially thought it would be.

Factor in sustainment costs into this over the life of the product and you begin to see that your investments in your software absolutely need to go through the same level of analysis as other types of large infrastructure purchases that non-software organizations go through.

I'm currently working on creating a lightweight model based upon Markowitz's Efficient Frontier investment model that money managers use today to ensure that your risk and return threshold is aligned.  I'll be posting my initial thoughts and approach in a coming blog.

Agile Planning and Delivery

Agile is often viewed as the way that small organizations and teams can build product quickly and in fact I believe that to be true. Being quick and nimble allows smaller/growing organizations the ability to get into a market quickly and deliver features that larger organizations haven't delivered yet or haven't thought of.

This very ability to deliver new features to a market that desires them is the very reason that larger organizations need to change the way that they deliver their product.  As an organization becomes larger, the entropy that comes from that growth causes the organization to stop being a market leader and start being a market follower.

In the technological world we live in, you can go from market leader to out of business in just a few short years.  I read an article recently that suggests that Walmart is starting to show signs that its dominance in retail may be coming to an end.  I wouldn't be surprised, as I think they have lost sight of the fact that low prices don't always solve the things we as consumers value.  Walmart isn't a market leader anymore, they may just not have come to that realization.

It's this lag in reality when big companies start falling behind  Somewhere along the way almost every organization will lose its way, lose site of the very thing that caused them to be great in the first place.

When you look around in the Agile learning space you see many of the original creators of Agile and Scrum trying to figure out how to help large organizations get past their own entropy.  I don't think that Agile can help, it can highlight where your planning and delivery processes are inefficient but it doesn't provide the language that senior management needs to hear in order to effect real change.

If we want to help organizations transform and be 'agile' then we need to speak in the langauge of management, which is money.  I've yet to have a cogent conversation with management regarding how their lack of focus costs them money and more importantly fails to deliver the speed to market that they need in order to stay market leaders.

If you think that Agile provides you with a means to quickly change product direction in order to play defense or catchup when new features that you have been planning on are released by a competitor, then you are missing the point.  Agile does accept that change will happen, but we expect that the change will take the form of measured change in how we can make the product more valuable, not wholesale changes in direction.

Changing direction within a Sprint is something I've seen several times and it's almost always driven by management.  Whether you have too many idea's/opportunities or are just trying to stay relevant give you team time to work on one thing at a time.  Context switching reduces productivity and that you can translate into money.

The example I've been using recently is this:

If you managed your Sprints the way you manage your money you would go broke.  Take this example for consideration (note this is what good Agile teams should be forcing into the planning conversation).

Consider a team that has planned 20 points for the current sprint and someone (Product Owner, Sr. Management) has decided that something else is more important, like completing a feature for a key client.  The appropriate response from your Agile team is 'Great, let the team review the request and provide an estimate'.  Right there you have probably lost 2-3 points in analysis and estimation by the team.  Once they have completed their estimation, they come back to you and tell you that it's a 5 point effort.

You think to yourself great we can do that in this sprint,  let's do it.  A good Agile team will tell you yes we can do it but you need to remove 2-3 points for the estimation effort AND 5 points for the new work that you want us to take on in the current sprint.  So you have LOST 7-8 points of productivity, aka value) to get 5 points of value.

If you invested 8 dollars into a business and only were able to get 5 dollars back you would quickly realize that you can't sustain that monetarily, right?

Put this to your executives next time you have a priority conversation.  I didn't even bring in the  technical debt we typically take on to hack something together and the lack of testing that will happen because we weren't ready to take on the work (read no automation).

As a Finance guy I would say that this is a bad investment.  Yes I want to satisfy my customer but if they are a good customer you should be able to have an ability to manage their expectations so that the team can take on the work in the next Sprint.  Depending on when the request came in they may only have to wait 2 weeks.

Effective teams I've worked with use this process as a first line of defense against changing priorities within a Sprint.

Scaling Governance in Agile

Large organizations who move towards and Agile delivery model may struggle with how to scale any governance model.

I think if you polled most Agilists about governance in general, you would tend to get a shutter and an ugly stare.  Indeed we want to address technical excellence during our sprints but what we often fail to understand is that software engineers are not omniscient when it comes to all of the areas of technical acumen related to performance, security and other compliance type efforts.

As an organization grows and becomes more and more global it finds itself dealing with many different governing bodies that each have different requirements for how we deal with data protection, which in turn relates to how we develop our software.

Having run PCI compliance for a large organization I know first hand that providing specific information to developers with respect to what to look for just in a code review is an important first step.

Governance is needed for most organizations as a first defense when something happens with respect to security/privacy.  Organizations need processes in place to provide evidence to governing bodies, courts and legal inquires regarding how we protect our product our customers information.

Governance can include both standards and artifacts.  For example PCI compliance requires that we provide evidence of compliance with respect to their 13 security requirements.   From a software development standpoint these include such activities as code reviews that are focused on security, software development cycle, evidence of secure development and test practices in addition other efforts such as  Penetration testing and other monitoring capabilities.

In Agile we need to think of this in a light weight manner.  At one organization we implemented a set of standardized stories, non-functional, that were to be included into a teams feature development sprints.  For teams that are working on several sprint efforts before going into production this can work very well as the team is addressing this as part of the planning and estimation.  When the code is delivered to production the completed and accepted user stories (which have context as to what was completed) serve as the artifact for the PCI compliance (or other) auditors.

The engineers liked this because they were creating artifacts as they developed and from an organization standpoint we gained confidence in the fact that our code was being developed against high quality standards.

For Governance activities that relate to more ongoing product sustainment efforts the same standards need to apply however the manner in which we apply them within each sprint may be different that new product type efforts.  Automated testing and monitoring form a larger basis of maintaining the standard levels that we established in earlier cycles.

Recently I heard a statistic that said 90% of attacks can be mitigated by the basic block and tackle work that teams can do on a regular basis.

Governance doesn't have to be a bad name in the Agile space, we need to view it as part of our technical excellence efforts that form the basis of high performing Agile teams.

I think Governance is an area in Agile that is ripe for development especially at scale.

BDD - Step by Step Process Tutorial

As you might tell from some of my blog topics I'm a huge believer in BDD, not just as a means to automation but more importantly as a process that helps us define requirements more accurately. When we move into an Agile delivery model, many individuals struggle to understand how they are supposed to document everything that they used to put in their Product Requirements documents (or a whole host of other acronyms).  These documents formed the basis of our engagement with the business and with the teams that would ultimately deliver what the business thought they were asking for in the PRD.

There is an interesting game that has many flavors such as Social Telephone game, that for me, makes clear the issue with large documents that multiple groups need to review.  Each of us is individually focused on the things that we think are important and we often have different interpretations of the written word.  And as such as we work to deliver in our silos we move towards an uncommon understanding of what is being built.  I would argue that many 'defects' that are found are actually poorly interpreted requirements.

For those of you in highly regulated industries you know what I'm talking about.  The endless hours spent reading a single paragraph trying to derive the real intent and meaning behind the written word is exhausting and fraught with peril because if we get it wrong there are penalties and mad scrambles to implement a hack to make it work the 'right' way.

Software development is made hard because of these communication differences, be they cultural, language or other, they exist and they make it difficult to come to a collective understanding of what is being asked for.

User stories help break down this barrier as they define small pieces of a larger whole and place a value statement so that we understand WHY what we are being asked to build is important.  Many teams writing user stories leave off that important 'so that' statement.  Leaving off 'so that' leads to so what?

Behavior Driven Development, for me, changed the way that I looked at defining requirements because it removed the business language of things such as the business requires this, or the feature shall do that.  The statements sound powerful yet deliver little in real context for the teams to work from.

Breaking down user stories with BDD still leaves the team to work with a non-technical domain language and then provides a clear method of defining the behavior (positive and negative) for the teams to work from.

The power of context with the respective speed and quality it delivers can't be denied.  However don't be fooled that this is easy, it isn't.  Agile is extremely disciplined, something many miss on their way to the Agile party.  Done right it can take your delivery processes to new heights, done wrong it becomes just another new fangled process that doesn't work.

Below is a BDD tutorial that can get you started on your way to learning how to build contextually rich user stories.  Good luck and have fun!

BDD Training

Agile Testing

I was saddened to see that a meetup group that I managed for over two years was coming to an end because there wasn't anyone who wanted to take on the leadership role.  When I started at a Northern Virginia startup as QA Manager I was tasked with taking on the leadership role of the DC Agile Software Testers (DCAST) meetup. When I took over we had 25 people and when I left the group two years later  we had grown to a robust 450 and had developed a reputation as a place where QA professionals could meet to learn how they could be successful in an Agile environment.

I've always said that QA is the last to come around when organizations move towards Agile.  Early on in my career in Agile the QA leaders would tell me 'yeah you guys develop however you want and when you are done, then we'll test'.    The notion that QA couldn't test anything until everything was done (though in reality it never was) was strong.  The feeling of power in finding defects that were typically not defects but mis-interpretations of requirements was palpable.  The force was strong with us then. (cue the light saber sound).

With DCAST I saw quickly that the people who were coming didn't understand how they could engage in the process and more importantly they didn't understand how they could deliver 'quality' without having the entire feature delivered for testing.  Iterative testing just didn't compute.

There are many things that QA teams need to understand in order to be successful in Agile.  Some of the key elements include:

1. Automation - For QA this needs to be a key focus of development.  Automation builds what I call 'progressive regression'.  Instead of thinking of regression as the final end to end activity, look at it as a growing entity.  With waterfall development and more manual focused testing, you get an opportunity to perform a full regression test potentially just once at the very end of the development cycle.   This leaves little time to deal with defects that arise from your testing.  With automation and continuous integration you are effectively performing a regression test of your developed features every night.
2. Behaviour Driven Development (BDD) - The two-pronged effort to quickly develop and manage your test automation suite utilizes example based test development like BDD as your test acceptance framework.  What BDD does is ensure that the entire team is reviewing the acceptance tests that will ultimately be developed as part of the automation suite.  This process ensures highly contextual user stories that clearly define the behavior of the feature and keeps everyone focused on exactly what needs to be developed (nothing more nothing less)
3. Parallel Teamwork - With the use of BDD, QA can develop their automation code while feature development is in flight.  If the teams are working from the same story specifications then when the code is checked in the automation should be able to run with few errors.  This is a key process to develop in order for teams to deliver quickly.  By not having parallel efforts, teams will typically fall into the cadence of having automation developed in the next sprint.  Once you go down this road you will typically see automation efforts begin to fall further behind as QA will start manually testing in order to 'stay on top of testing'.
4. Sprint Management - QA teams need to work with their team to ensure that work is being delivered throughout the entire sprint.  A common problem teams face in Agile is that we fall into the 'mini-waterfall' process where developers deliver the features in the last day or two of the sprint.  This leaves very little time for QA to perform ad-hoc and manual break testing along with fixing any automation breaks that have occurred once the code is checked in.
5. Zero Defect Policy - This is key.  Teams need to develop a working agreement that enforces a zero defect policy for new feature work in a Sprint.  This means that the team does not receive credit for any stories that can't be closed out with zero defects.  This focus ensures that the entire team is focused on delivering quality.
6. Quality is EVERYONE'S responsibility - There is no such thing as 'toss it over to QA' in an Agile world.  Hey Developers, you have to help test if you deliver something late.   Don't let your software engineers tell you that they don't test.  All great developers have to be good testers ( you know TDD kind of focuses on writing tests).  The entire team is responsible for quality not just your test engineers.   Note - QA Managers this concept in no way removes the need for your existent, rather like Engineering Managers your role changes.  You should actually have time to be strategic and plan out future testing platforms and approaches for your team.

I'm glad to have led DCAST as it provided me an opportunity to help QA professionals grow their understanding of the activities and process all good Agile teams exhibit.