Agile Development

Launching SoundAgile Consulting

I've been involved with Agile with many different organizations now for over 12 years. In these years I've primarily been involved with being a contributing individual over a being an Agile coach.

The business of Agile has grown to a significant size and has now become a product that is sold to businesses who want to move their organization to Agile.  The very people who started Agile off as a movement have splintered off into several factions, each having their own opinion or approach in how to help organizations adopt Agile as a capability within their organization.  We now have Scrum, SAFe, DAD and LeSS to name a few in our acronym vocabulary.

Agile can indeed bring about valuable changes to an organizations ability to deliver software product more quickly.  These areas of Agile are fairly thought out, User Stories, Continuous Integration, Automation and Scrum.  You can move your development teams to a faster pace with some focus on specific team and development techniques that require some time to learn with some level of ease.

What Agile is struggling with is at the organizational level.  The Agile manifesto is specifically focused on building software better with a goal of delivering high value and quality software to our organizations.  A noble cause for sure and one that was sorely needed, given the changes in our software capabilities over the past 20 years.

Sr. Leadership however hasn't changed much, still managing in a large up front analysis budgeting process which creates a painful friction between fast moving product delivery teams and slow moving hierarchical management structures .

For those organizations who are being sold Agile as a product that will deliver 'x' benefits know this about what is occurring.  These organizations are finding people who have done 'some' to 'no' real Agile, meaning they haven't actually worked on an Agile team. Getting people who have the 'right' certifications doesn't provide those people with the ability to coach teams in the reality of Agile, only the theory of Agile and their current frameworks.

They are also focused only on the product development area of your business, letting you believe that you will receive huge benefits from moving to Agile without the corresponding changes necessary throughout your entire organization to support a fast paced product delivery teams.

Agile is not a small change management effort, rather it is a multi-year impact to your organization, that if done well will lead you to great success.  If done poorly will provide you with significant pain without any corresponding benefits.

I've spent many years thinking about what I might offer from an Agile consulting perspective and I've come to the conclusion that any Agile 'consulting' work that I would want to engage in must include both Sr. Leadership down and the team level.

Another thing I have concluded is that successful organizations that want to become Agile, must do so with a much smaller footprint of coaching.  You don't need full-time coaches for a long period of time.  In relying on full time coaches you are asking them to be your organizational Agile cop over owning the change within your organization.  The most successful Agile organizations I've worked in never had an Agile coach. Let me repeat that, never had an Agile a coach.  Instead they owned the move to Agile from the top down.  They provided the opportunity for teams to be empowered and fail and were not afraid to change organizational processes when they became impediments to improving Agilty.

SoundAgile will provide two levels of support and coaching for your organization.

  1. Team Level - Coaching and training will be accomplished through a combination of online training videos, 1:1 coaching and targeted onsite sessions for specific techniques such as Discovery/User Story Mapping, User Story Writing and Behavior Driven Development.
  2. Management Level - This will cover every management level in your organization, especially focusing in on your most impacted people, your technology managers.  Coaching and training will again be accomplished utilizing videos, 1:1 coaching and probably most importantly, targeted 1-2 day sessions that will continue for a multi-year time period. These sessions will provide for a longer term inspect and adapt change management process.

I'm really excited to be launching SoundAgile and am looking forward to working with people and organizations as they engage and encounter this thing called Agile.

SoundAgile will be live within the next two weeks.  I look forward to working with people who are motivated to move to Agile and make it work for them and their organizations.

Top Down or Bottom Up - Large Scale Agile Adoption

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

Bass_Guitar

OR this?

Bass_Fish

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.

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.

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.

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.

PMO Role in Agile - Part 2

My initial blog seemed to have some interest judging by the number of views it's received so I'm guessing that it's a topic that many are looking for input on.   So I thought I'd provide some more thoughts as to what a PMOmight  look like in an Agile organization. One of the key things that changes with a traditional Project managed organization is that they must change to one that is Product managed.  What this means is that the organization changes the way that it funds its business by essentially providing Product Owners with Scrum teams that will deliver on their vision for their product.  Given this paradigm, along with the creation of the Scrum Master role, the PMO and subsequent project managers are left outside looking in.

Managing Product driven teams means that you are managing towards outcomes that delivery value over projects that deliver features.

In my previous post I provided some suggestions as to what individual Project Managers could do to make themselves more valuable and productive to their teams.

In this post I will suggest a PMO structure that focuses on the Portfolio view and leaves the operational execution of the roadmap to the Scrum Teams and Product Owner.

For this structure to work the organization needs good Scrum Masters and preferable ones that aren't also individual contributors for their team.

The structure of the PMO will be lighter than you might think is right, but I'll argue that if you have the same number of Scrum Masters and Project Managers you will set up role confusion that will make your entire project management process cumbersome and less productive.

The PMO structure would look something like this:

PMO Org View - Agile

I think one of the things that a PMO organization needs to be aware of is that their focus is not on control of projects and people but on how teams are performing.

With this structure you have a thinner level of Project Managers who are focused on Program level Product Management (PPM new acryonym anyone?). Your Project Management function becomes one of oversight of Scrum Masters and working closely with Program Managers in other Product groups who probably will have cross org dependencies.  The Program Manager level in this structure is more about working to ensure that teams are working on the right things based upon the Product Roadmap and escalating when individual team priorities become out of line with the overal corporate product objectives.

What we want with a PMO is confidence and how we do that historically is to place controls, gateways and processes designed to show that teams are checking off boxes that we believe represent how a successful project should unfold (aka Project Governance)

How we do that in an Agile organization is to ensure that our teams we have a clear Product roadmap, that we are performing effective planning both in the areas of Product Discovery and Release Planning, that teams are provided time to review and estimate the work that they are being asked to commit to AND ensure that teams perform continual inspect and adapt cycles via Retrospectives.

If teams are allowed to form into solid high performing teams what you get from that is an organization that learns how to estimate accurately, which leads to consistent velocity which in turns leads to predictability....which is what we in the PMO (and Sr Management) are looking for, simple right?

What I learned years ago from my Project Management days is that Agile actually provides you with much more visibility and transparency about what is happening with your commitments,  providing you as the stewards of the product an ability to have fact based conversations with stakeholders who rarely understand the complexity of what they are asking for.

BDD - Breaking down stories

One of the areas that many teams struggle with is getting user stories to the right level of context.  For me context IS everything in user stories.

 Yes a story is a placeholder for a conversation, but with large complex systems and organizations, the need to build out (and document) context has many benefits for teams and the organization.
Over the years I've seen some consistent elements fall out of BDD that can provide teams with an understanding of when a User Story may need to be broken down.
As you begin to build your test scenarios for your user story ensure that the story has no more than 3-4 scenarios.  If the number of scenarios is large, getting a clear contextual understanding of the story becomes much harder.  Additionally if automation is part of the equation then you end up with a larger code base for a single story and it can make trouble shooting failures harder.  Smaller stories mean less complicated acceptance criteria and more manageable and scalable automation code.
Once you have identified your test scenarios and begin writing the supporting BDD acceptance criteria look for some of these elements as queues to potentially break down your stories:
  1. Large set of parameters- If you see that you have more than 7-8 parameters in an individual test scenario consider breaking the test into additional scenario(s) or another story.  As I've taught my teams, if you see your example table stretching off the page you probably need to break it down.
  2. Large set of examples - If you see your test has more than 12-15 examples in an individual example table, you should consider breaking it down into additional scenario(s) or another story.
Keeping your stories and test examples small ensures that the team can more accurately estimate, deliver and demo their work consistently.
Teams should strive to break stories down so that they are small enough to be completed (Dev and Test) within 2-3 days.  This level of granularity provides clear visibility during Standups if the team is on track to deliver on their commitment.
Many teams suffer from what I call 'pushing a river down a creek' syndrome.  Meaning that they don't perform sufficient planning and story breakdown which leads them to continue to push their work out into future Sprints.  This leads to a lack of visibility as to when 'it will be done/delivered'
Breaking down stories effectively also leads teams to have stable velocities which leads to predictable delivery.  All of this feeds improved Program and Project management across the organization.
Organizations that need to scale Agile need to understand that this level of discipline isn't easy, but we shouldn't shy away from something just because it's hard.
BDD story breakdown leads to vastly improved feature definition, scalable automation suites and a strong automated regression.

BDD - A team oriented activity

Probably one of the harder elements of Agile that teams struggle with is the art of collaboration. Our experiences over the years have taught us to treat functional groups such as BA's, Devs and QA as separate entities each with their own perspective and each distrustful of the others abilities to deliver.  How many times in QA do we hear the phrase 'Just toss it over to QA and let them deal with it'. 

We forget so easily that what we deliver for a customer is the sum total of our efforts, not just of individuals.  The Chicago Bulls were a good team with just Michael Jordan, but only when they were able to blend ALL of the skills of the team were they able to win championships.  Scrum is about team.
Getting your Scrum team to actually work as a team is one of the key efforts that everyone needs to make and BDD is a way that can help teams  work collaboratively to  build what I call contextually rich user stories.
You can't rely on just one or two people to write user stories and acceptance criteria as there is a limit to the context of what any one person can know.  With ever growing complexity in business and technology the more people who can collaborate the more context that is captured in the story.
Does it sound like heavy overhead?  It shouldn't.  I'm sure you have all spent hours pouring over Business or Product Development documents trying to glean enough information to build a design that will work for the next 6 months (which we know doesn't happen on any planet in this solar system).  We've always spent time trying to understand what is being asked for but in Agile we spend smaller increments of time on writing details that matter.
The most successful teams I've worked with have adopted this type of approach for building out BDD acceptance criteria:
  • Start of Sprint -
  1. During the first two days of the Sprint the QA lead and Product Owner work together to develop (and or complete) BDD acceptance criteria for the next upcoming sprint.
  2. By day three the development team should start delivering stories to QA for testing.  Additionally QA can begin their automation efforts via BDD examples with tools such as Cucumber, Fitnesse, Capybara....
  3. The engineering team needs to plan to complete all of the story development so that the last two days are open for them to  review the acceptance criteria and make changes/suggestions to the PO.  The team is also completing their designs for the upcoming sprint during the last two days and fixing any bugs that are discovered in testing.
BDD Planning Cycle v1.00
The key to this process is that before the team commits to the sprint they must all review and agree to the scope of the BDD acceptance test examples.  Without this discipline, the scope of the story and sprint will not be as precise.
As I've told my teams in the past, moving to writing BDD acceptance criteria is a mind shift in how you view both requirements and testing.  Both Development and QA can consume them for their individual efforts, but in the end, if they work against what is defined in the BDD they will both be on the same page functionally.
BDD takes the guess work out of what is being developed and that's a good thing.  For Sprints to go quickly and with high quality,  teams have to understand exactly what they are doing.  To steal from one of my favorite phrases from Bull Durham 'Don't think, it only hurts the ball club'.
BDD provides clarity for the entire team and makes demos go smoothly.
Ensuring that the team provides input, review and commitment to BDD acceptance criteria keeps everyone focused on doing just what is needed.

Being Agile - Say it, Do it, Prove it

I was working with a team recently and as we talked about all of the planning that Agile entails, I broke it down into very simple terms - Say it , Do it , Prove it. That is really what Agile is about.  Anything else outside of these three concepts is noise to your ability to deliver product and services to internal and external customers.  As Product Owners in an Agile organization, you need to understand all of the effort and dynamics involved in getting your teams to Say it, Do it, Prove it.

Delivering what you say you are going to deliver is the best way to build credibility with your stakeholders.

For Agile teams, this translates into being effective at decomposing your stories into small enough increments so that you are confident in your understanding of the user story and estimates that the team believes in.

  1. Say it = Release Planning and Backlog Grooming -
    1. Starting at a high level, the Product Owner is responsible for saying what is important to the organization from a value standpoint and beginning the process of developing a user story backlog that supports this vision.
    2. User story decomposition is so important to effective Agile teams and the Product Owner must start with a set of well-formed stories that provide context to the team.
    3. What is 'context'?   Context is anything that provides definition.  It is basically what the product should do from a functional standpoint.  One of the biggest mistakes many teams make is writing declarative stories that start with the 'How'.  This,\ in turn,  puts the technical team on the defensive as they may have many different ways to implement the feature.  As a Product Owner, be sure to steer clear of writing stories that define how you think the feature story should be implemented.  I know that as we all become well versed in technology there is a strong desire to show off our technical chops, however, as a PO you need to provide context from a business standpoint that your tech teams can consume. I've heard time and again from engineers that they would really like to understand how what they are developing delivers business value or solves a particular pain point for the customer.  The team works much more effectively when they are completely grounded in the business context of what they are building.
  2. Do it = Sprint execution 
    1. An important element for teams to address once they are ready to take stories into a sprint, is that the goal during the Release Planning and Backlog Grooming activities was to begin to build out the context of 'How' the story will be implemented.  It is so important for teams to understand that there is essentially a handoff from the PO to the Scrum Team and that each of them is responsible for building what I call contextually rich user stories.  Gojko Adzic calls this Specifications by Example.  Effective teams who deliver fast and with high quality work closely as a team.
    2.  I believe that the combination of User driven stories and context driven specifications (examples) forms an extremely strong definition of both Ready and Done. which is why I coach my teams to utilize BDD as the basis for developing their User Story acceptance criteria.  The team works together to complete BDD acceptance criteria forming a clear understanding of the boundaries of the feature.  This provides the PO with a concise view of what to expect during the Demo.
    3. Another key benefit of writing BDD as part of your user story writing is that the test automation engineers can easily consume this as part of their code development for the automation.  PO's should push to get to this level of context as it also means that your test engineers can start developing their test automation code once the story is ready for development.  They can essentially perform TDD in that they can write their automation before the feature is actually developed.  Once developed the automation should run cleanly and both speed and quality are attained.
    4. The goal of teams should be to deliver user stories that do not require much further elaboration once the sprint begins.  You want your teams focused on delivery ,not on discovery.
  3. Prove it = Retrospective
    1. You have done all of the work to clearly define your user stories with high levels of context.  With all of this effort, the Retrospective should be an easy affair to show the work that was defined in the stories.  The PO should not have any surprises.  In fact, if the team misses any test scenarios after the story has been started, the PO should consider that more of a missed requirement over anything else.  Since the entire team developed the stories,  there can be no finger-pointing at anyone.  It was a shared miss and everyone must accept it.

It sounds really simple when broken down into these 3 basics phrases.  The truth is that 'Being Agile' is much more involved than simply 'Doing Agile'.

"Being Agile" means exposing all of the inefficiencies in your product development processes.  It requires that the organization be completely honest in assessing what is not working and committing to letting the teams that do the work fix these processes.  You cannot top down drive the type of organizational change that is required for Agile continuous improvement.  Real organizational change is fostered at the top but truly owned by the Scrum teams that form in support of any Agile adoption.

Sound Agile - Aligning Agile with Soundness

As I indicated in my last post I renamed my blog to Sound Agile and I'll be writing about Agile from the perspective of Soundness and how organizations should be evaluating their Agile adoption. I spent quite a bit of time trying to decide what I wanted to name my consulting business and blog (both are called Sound Agile) and I ultimately wanted to convey what I have seen as successful with respect to the teams and organizations I have worked with over the past 10 years.

Thanks to my wife for providing me a word that when I looked at it provided me with the right context to what I had been trying to convey.

Sound: 

adjective

1. free from injury, damage, defect, disease, etc.; in good condition; healthy; robust: a sound heart; a sound mind.

Supporting Manifesto - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

a. Free from Defect - Speaks to Quality that we strive for in Agile. b. Healthy - Speaks to your employees health and well-being c. Robust - Speaks to building scalable products. d. Sound Mind - Speaks to teams keeping a clear and open mind to improve

2. financially strong, secure, or reliable: a sound business; sound investments.

Supporting Manifesto - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

a. Sound business/investment - Speaks to the value proposition that Agile focuses on. b. Financially strong, secure and reliable - Speaks to the ability of Agile teams to delivery products that are foundational to your organizations long term health and security.

3. Competent, sensible, or valid: sound judgment - This speaks to trusting that the people that you are hire are compentent and when following Agile ceremonies such as Standups, Retrospectives and Planning are able to deliver product that is built on solid decisions.

4. Having no defect as to truth, justice, wisdom, or reason: sound advice. - This speaks to the continuous improvement and Retrospectives that drive this effort.

5. Of substantial or enduring character: sound moral values - Speaks to team commitments, believing and supporting themselves, the foundation of Scrum.

We spend so much time writing and talking about things that we should, could, might do to deliver Agile,  We hear people talk about how 'Agile' are you, tell people that doesn't 'Sound Agile' and I think we have muddied the waters of what Agile should be.

When you hear Sound Agile you may be inclined to add an additional adjective 'Sounds Like Agile' and to some degree that is expected.  My focus however will be on the soundness of Agile from the perspective of organizational change an area that isn't really talked about as much as the other elements of day to day Scrum.

I look forward to comments and input to my blog as my writings will form the basis for the types of coaching and consulting I hope to do in the future.

Technology isn't important, Product is

We are so enamored with technology today, what it can do, the excitement it brings to us as technologists that we have lost sight of the fact that technology isn't the end game for a business. Why?  Because if your organization could figure out a way to run their business so that it wasn't dependent upon technology they would do it in a heartbeat.   The people who own and run businesses don't care about the underlying technology, even those who classify themselves as technology companies.  At the end of the day technology enables the business to develop product.  They aren't in the business of  developing technology as  end product and I think that goes for companies who deliver 'technical' products.

Many teams I've worked on in the past 10 years have isolated themselves from the organization, instead telling stakeholders they were  focusing on technical excellence.  Leaving the stakeholders wondering why they weren't delivering what they wanted all in the name of technical excellence.

I worked on one project that was so late that the business ending up exiting the market that they were in.  In response the Development manager said if only the stakeholders knew how cool the technology was that they had worked on they would change their mind.  Really?  They could care less, all they wanted was a product that would keep them in the market and making money.

Though the amount of information we can process has exploded we aren't really solving really new problems, they are just much larger in scale and are required with much higher availability.  At the end of the day business runs on information that drives product decisions that build value.  Like any other part of the organization we are responsible for delivering value, not technology.

If we could deliver data to our business without all of this cool technology like hadoop, etc....they would be just as satisfied.

We should spend much more time on how we can deliver what we need for the business with less over building systems that continually build in complexity because we aren't product focused.  Think about it, organizations that deliver at scale, such as car manufacturers continue to refine their processes so that complexity is removed, whereas we seem to have to add complexity in order to deliver value.  They add technology where it makes sense not just because it's the latest thing.

Technology isn't important but our technical product is.  We have architects, tech leads, dev managers, however I don't often see them actually defining the technical product that the business needs, rather they evaluate specific pieces of it, SQL server over Oracle, Java over .Net, etc.....and with each iteration individual personalities can influence the type of technology being implemented, often times in direct competition with the documented tech stack that company operates in.

What we end up with is a technology product that doesn't scale well and adds cost to the organization in both resources and revenue delays.  When confronted with the mess we've made we tell the organization that can solve the problem with a new platform.  Unfortunately we often fail to fully deliver on that promise for the same reasons that we got into the situation in the first place.

This is not to say that we don't try to build systems right. Executives also need to bear responsibility for not providing the Engineers you have hired the support and time necessary to actually build technical products that deliver value to your business product, they are one and the same in today's world.

When your technical team is forced to meet dates, the inherent compromises that need to be made typically result in short cuts to your technical product in order to deliver the most for your business product.  You can do this in the short term, but if you don't provide your teams time to shore up these short cuts your technical debt continues to grow.  And like any debt you eventually have to pay it.  Pay it at the end of every release like a credit card you won't incur finance charges.  Continue to pay just the minimum and you eventually can go bankrupt.

Member Login
Welcome, (First Name)!

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