Lots of carryover? Try swarming

swarming4Scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.

If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun. Plus, a backlog item that is 90% complete does not make the company money so the team discusses in the retrospective how to prevent that from happening again.

I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach. Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog. On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is two to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:

  • Keep the team working together closely and will result in less context switching
  • Keep the intensity level high on getting impediments resolved ASAP
  • Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
  • Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day

The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Agile Velocity, Enterprise Agile, Kanban, Scrum Development, Scrum Methodology | 4 Comments

Agile Beyond Software: A Manifesto For All Industries

Lean ManufacturingWhen the Agile signatories created the Manifesto, software was obviously at the core of their thinking, which makes sense as they were all building software at the time.  As it has grown in its popularity, however, Agile has gone beyond software.  So, should the original Manifesto be adjusted to accommodate these new adopters?

There is an ongoing debate about whether Agile is only for software development or whether it can be applied to other industries.  In order to even attempt to see if Agile could be applied, we should first take a look at the original values and principles, which you can find here: http://www.agilemanifesto.org.

With that, here is a stab at what it might look like if it were to change. I’ve underlined any text that has been altered from the original:

Manifesto for Agile Product Development

We are uncovering better ways of developing
products by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working products over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Here are the principles with changes:

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable products.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working products frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

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

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working product is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Okay, so there it is.  Yep, it’s that simple, I just changed the word “software” to “product”. Maybe you think there could be issues with some of these values or the principles if they were applied to other-than-software production.  I’d like to hear your thoughts.  If you have other industry experience, would these be good to apply to your industry?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Marketing, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Kanban, Lean, Scaling Agile, Scrum Development, Uncategorized | Leave a comment

New ScrumMaster Tips

Team

I recently completed a blog on PMs transitioning to a ScrumMaster role.  I was inspired to put together a quick blog post for new ScrumMasters after reading a question that was posted to social media.  The poster basically wanted to know how to drive the team without them reporting to him/her or having “control” over them.  When I first read this I was perturbed but quickly thought to myself this person could be new to Agile and Scrum.  I’ll refer back to my definition of a ScrumMaster, a servant leader who is an Agile champion for your team.  I didn’t say management leader or controller or mother of dragons.

The ScrumMaster role is very challenging role and it takes some self control for people coming from a different role such as a PM or a lead from the team.  I am not a fan of “working” ScrumMasters, meaning they are also coders or leads.  They need to resist the urge to roll up their sleeves and dive in.  A good example of this, I was working on a Legos4Scrum (By Alexey Krivitsky) exercise acting as ScrumMaster.  Legos4Scrum is a cool way to introduce Scrum during an Agile bootcamp. You basically have teams working with sprints building items for a city while working with a product owner for vision of the city.  All the other teams had working ScrumMasters meaning they were diving in helping to build items such as schools and hotels for the city.  I was not building anything, instead I was separating the bricks, breaking bricks apart, sorting into colors etcetera making it easier for the team to build. Can you guess which team achieved a higher velocity? The team with a ScrumMaster who was constantly making the team’s job easier.  I was also working with product owner with any questions the team had as they were building. I tracked down the product owner if need be, not the team member working.  Do whatever you can to keep impediments down and efficiency high!

The servant leader side of the role is rewarding but being an Agile champion is crucial.  If you are new to the role start to soak up as much knowledge as you can.  At the end of the day you serve as the Agile coach for the team.  You should know the ceremonies and fun ways to facilitate them.  I highly recommend joining groups out there in internet land.  If you have a local Agile group join it, attend the meetings and share your experiences.  You will never stop learning.  Your knowledge and ways to handle situations builds trust with the team.

Another piece of advice I have is to provide a fun environment for your team.  Anything you can do to achieve this whether it is adding some cool posters or getting that energy drink fridge installed.  Try coming up with fun ways to do the standups and retrospectives.  If your team has the personality for it a prank doesn’t hurt from time to time.  Now remember don’t rewire the power switch on a PC to a remote power switch unless they can take a joke.  That was one of my favorite pranks I’ve ever been apart of.  Soft dart guns can also be very interesting on Friday afternoon.

I have only scratched the surface, this is a topic I could type for days on since I am very passionate about it.  That being said if you are a ScumMaster and have some tips please comment for those new ScrumMasters out there!

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology | 1 Comment

What does it really mean to be an Agile Tester?

I was a QA Lead back in the mid 90’s for a couple of years, before any of this fancy Agile stuff really started taking off. Waterfall all the way back then; mostly manual testing, with full regression cycle at the end. Hurry up and wait, then go like hell given some ridiculously small window of time remaining before we had to release to Production. We started to dabble with automated testing tools, but they were difficult to use at the time; you almost needed to be a programmer. But a lot has changed since then.

What I learned more recently, in making the move to Agile testing methods and away from these more traditional QA functions, is that it’s a really big undertaking.

For those Testers out there who have yet to really dive into the deep end of the pool with Agile testing, let me just tell you this… you have never been so important in this new Agile world.

I think it’s this ‘whole team’ approach that’s probably the biggest difference between Agile and Traditional Waterfall development.

All for one

As an Agile Tester, you’re a full-fledged, first class member of the Agile Team. All for one and one for all!

You may be saying to yourself… “That sounds nice. And I don’t disagree on the Three Musketeers cheerleading you’re doing here, but I’ve heard that before. Be a bit more specific; What does it ‘really’ mean to be an Agile Tester?”

OK, allow me to elaborate…

For starters, it means that as an Agile Tester, you actively participate in planning, estimation, scheduling, retrospectives and any other activities of the team. You’re no longer in a QA silo where you only come out to play near the end of a project or release.

It also means you’re not the only one on the team who can test, anybody can. But no need for concern; you’re still the best equipped to do so. In other words, you’re job isn’t going anywhere. And more good news; you have help when you need it.

It means that you embrace change; you collaborate well with your team members as well as those outside the team.

It means you know how to help other folks on the team automate tests and help drive exploratory testing.

It means you put yourself in the customer’s shoes, and understand where they’re coming from, what their needs are. You’re empathetic, and can see the big picture.

It means you possess a unique perspective in the way things should work, and can help identify any potential roadblocks and dependencies sooner rather than later.

It means you guide other folks on the team, helping them improve upon their testing knowledge.

It means you work closely with the developers, sharing your skills and knowledge with each other; developers helping testers with some of the more technical aspects of creating automated tests, for example.

It means you work closely with the Product Owner, guiding and helping them understand the acceptance criteria, and final verification of what it means for a user story to be ‘done’.

It means you’re involved heavily in the design of the user story’s test cases prior to Sprint Planning. This helps your Sprint Planning Meetings go more smoothly. You groom your test cases in much the same way a Product Owner grooms their product backlog.

It means you’re an explorer. You’re systematic in the way you work, you pursue anomalies, and you think about what folks on both ends of the spectrum would do.

It means you radiate information. You open the doors and provide visibility into all testing activity. Things like ‘Testboards’ that display test status and progress, defects reports, impediments, trends, etc.

It means you’re heavily involved in the estimation process, helping folks understand the acceptance criteria for the user stories, and helping to refine them along the way.

It means you actively participate in Sprint Planning, identifying individual testing tasks. Things like preparing the testing data, executing the tests, exploratory testing, test automation, etc.

It means you help the Team decide what it means for a story to be ‘done’. Things like… code complete, unit tests written and executed, integration tested, performance tested, documentation completed, etc.

It means you understand and can articulate the difference between an ‘issue’ (a problem that occurs ‘during’ the Sprint and it coupled to a user story that hasn’t yet met its definition of done) and a ‘bug’ (identified ‘after’ a user story has been completed and accepted by the Product Owner). Bugs are included in and prioritized in the Product Backlog Item. Issues are not.

In particular, it means you understand the 2nd line item in the Agile Manifesto very well (working software over comprehensive documentation). Meaning you get the importance of face-to-face communication over formal documentation of all bugs. Be lean.

It means you address issues head on. We all know the sooner an issue is found, the cheaper it is to fix it. Make sure you practice this, and the folks on the team do too, and put it into practice.

It means you understand the importance of automation, and help the team put into practice stuff like automated testing, continuous integration, build-deploy automation, and continuous delivery.

And yes, it means you actually run tests too, whether they’re automated or manual.

Yea, I know; this is a lot to take on. Start small. Make progress in chunks. Be empirical. Inspect and adapt.

If you’ve made the move to Agile practices, what have you found to be the biggest difference when it comes to testing? What are some of your biggest struggles?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Agile Testing, Continuous Integration, Distributed Agile, Enterprise Agile, Iterative Development, Scaling Agile, Scrum Development, Scrum Methodology | Leave a comment

Agile Beyond Software: GM Case Study

Car EngineThere is an ongoing debate about whether Agile is just for software or if it can be extended to other industries.  I for one believe the Agile values and principles can be applied beyond software, but, in a recent discussion about this, a colleague raised a concern that some of the principles would be difficult to apply for some industries.  The principle in question: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

The thought here is that manufacturing industries have a high cost for changing once production has begun. This is true, it can be costly to change since production has to be stopped, parts changed, processes reconfigured, delivery would likely be delayed and there is cost in correcting any issues in products already produced.  However, one cost that is often dismissed is the cost of not changing.

Let’s consider the recent case with GM and the ignition switch malfunction.  According to several reports GM has issued a recall on about 2.6 million vehicles to repare the faulty ignition switch.  For arguments sake, let’s just pretend that the cost of the part and the cost to have a post production mechanic replace it is the same as the original.  That means for every replacement, they are paying double the original cost.  Then there are the costs for the accidents caused by the malfunctions, and the biggest cost, the cost of lost lives.  How do you put a price on that?

So, I think we can safely surmise that GM would have spent less money had they replaced the part when they found the issue.  What we should consider next then, is whether they could have replaced it, even late in development.  According to the graphic in this NBC article (http://www.nbcnews.com/storyline/gm-recall/infographic-when-did-gm-know-it-had-ignition-switch-problem-n68611) provided by Ronnie Polidoro, GM first found out about the issue in 2001.  Apparently they also dismissed a partial fix in 2005.  Now it’s 2014 and they have finally issued a recall.

It seems clear to me that, in this situation, accepting the change in requirements would have been easier and less costly than going with the chosen path.  It certainly seems that it would have at least been in the customer’s best interest to do so.

What are your thoughts?  Do you think Agile principles could be applied here?  How about Agile beyond software?  I look forward to your comments.

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Enterprise Agile, Lean, Scaling Agile, Uncategorized | Leave a comment

So you’re going to be a ScrumMaster?

Team“Well I am a PM now but they are making me a Scrum Master.” I have heard that statement countless times. Some PMs are happy about the new challenge, some aren’t and some just want to keep making those Benjamins. I have to admit even though being an embedded software engineer by trade the ScrumMaster role is my favorite role on a Scrum team. When asked what is a ScrumMaster I always respond with a servant leader and Agile champion for your team. Yes there are more details but I think simple is the best approach sometimes.

I thought it might be a nice time to talk about some of the qualities that a great PM has and how those look in an Agile environment. PMs tend to get a bad wrap from the Agile world so lets clear the air. I just so happen to have a fiancee that is a PM for a large company. She tries to give me a gantt chart for the week and I hand her story cards daily at breakfast. I asked her to take a survey of her peers which consisted of development, product management and other PMs. They came up with five qualities a PM has, here they are in no particular order.

Issue / Risk Assessment
Issue Resolution
Listening Skills
Manage Expectations of the Business
Process Oriented
On the topic of issue/risk assessment I can help your stress level by letting you know that issue assessment and risk assessment take different routes. Issue assessment gets the chance to happen everyday in team’s standup meeting. Of course if this is urgent it may be brought to your attention sooner. Risk assessment is happening all the time by way of the entire team. Is the sprint going to be completed, what stories might be slipping and what can we do as a team to deal with that.

Issue resolution is a key quality that will carry over. As a ScrumMaster you should do everything in your power to resolve issues or impediments for the team. This not only keeps the team adding value all the time it also builds their trust in you as the ScrumMaster. Issue resolution also requires a good listening skill.

Listening is a skill or quality that I think everyone is challenged with in life. Listening before you speak, listening before you start to think of your response etc. ScrumMasters have to fine tune this skill, even when it makes things uncomfortable at times. Some ScrumMasters tried to lead the team too often with words. I am a fan of posing the question and then letting the silence get uncomfortable enough that someone from the team answers. Which breaks the ice and conversation begins to flow. This also starts the baby step path to the team becoming more and more self organized.

Our next quality, managing expectations of the business, which is easier now! You get to manage it two weeks at a time or however long your sprints are. You will work with product owner to sprint plan and release plan if you are making use of that planning method. Better yet, let’s remove manage and add rank. Ranking is what a product owner is doing with the pieces of the value the business is looking for. Your job as a ScrumMaster may be to help the product owner provide details necessary to get the conversation and collaboration going! Those specs are you are used are gone and I challenge you to ensure the story doesn’t turn into a spec.

Being process oriented is good thing since you have new processes to learn. Scrum as a concept isn’t hard to understand but mastering it can take quite some time. That being said a Scrum team can take a year or more to fully mature. A good ScrumMaster is more than a certification, not to knock them. You will have times when you have to figure out the best way to passively guide the team towards better Agile values. You have to truly believe that what you are saying has value and can be successful.

So I go back to my definition, a servant leader and Agile champion. Live everyday for those around you and remember the values that Agile stands for. Go have fun with the rest of the pigs! (Search for it) I’m sure I didn’t paint rainbows and unicorns for the PMs out there reading this. I can assure you the ScrumMaster role will be one of the most challenging and enjoyable roles you’ve ever played on a team.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 10 Comments

Why Agile Governance Matters at the Project, Program and Portfolio Levels

Guest post by Monte Montoya, cPrime

For any organization attempting to migrate to – or sustain – agile processes, governance is an important consideration. This is especially true as companies grow. While small companies can likely get away with fairly informal governance, larger enterprises cannot function effectively without formal controls in place.

As we touched on recently in the article “How to Develop Your Own Recipe for Agile Governance,” every organization can benefit from developing its own unique “recipes” for agile governance that fit the organization’s specific needs and projects.

But why does governance matter so much? Let’s break the answer down into three categories: the Project, Program and Portfolio levels.

Agile Governance at the PROJECT LEVEL

To keep our terminology clear, we’re considering a project to be “a temporary endeavor undertaken to complete a unique product, service, or result.”

Effective governance at the project level identifies and advocates for specific goals to be reached during each sprint or iteration. It helps determine the core requirements that comprise the initial release of the project and the criteria by which additional goals will be decided upon.

Since multiple projects may be closely interrelated, effective Agile governance is often achieved at the program level where these multiple projects interface with broader business objectives.

Agile Governance at the PROGRAM LEVEL

A program can be defined as “multiple related projects that are managed in a coordinated fashion.”

At the program level, the more comprehensive strategic goals of the organization filter down to individual projects that produce tangible results. Therefore, this is the optimal location for Agile governance to stem from.

Managers at the program level are in a key position to fully understand the requirements of each individual project without being directly responsible for negotiating the details. They are also in a position to understand and translate the overarching strategic goals of the organization to project managers who may otherwise suffer from tunnel vision.

Agile governance also provides managers at the program level the means to monitor and report on the progress of projects under their oversight.

Agile Governance at the PORTFOLIO LEVEL

A portfolio is a collection of programs or projects and other work grouped together to facilitate effective management in order to meet strategic business objectives.”

Managers working at the portfolio level are primarily concerned with organizational strategic goals and may have limited knowledge or understanding of individual project successes or failures. However, they do need to know the general direction in which the company’s projects and programs are headed, and they will concern themselves with business continuity matters such as budget and time line more so than those in project teams.

As utilized by the program level, effective Agile governance allows for clear and measurable monitoring of individual projects and broader programs in a language portfolio managers can understand and work with: time, money, and personnel.

Help For Those with RAGE Issues

Establishing effective Agile governance is a potentially complex and difficult process.

For help in making it happen for your organization, take a moment to review our Recipes for Agile Governance in the Enterprise services.

Learn more about RAGE at the Project, Program and Portfolio levels by checking out our RAGE Introduction Webinar:

Posted in Agile Adoption, Agile Portfolio Management, Enterprise Agile, Scaling Agile | Leave a comment

It Isn’t Agile; It Is Life!

One of the things I like to start with when introducing agile development is the quick application of agile development to life. I ask the question: “Did you plan today six months ago? Did you plan getting out of bed, then taking a shower, then brushing your teeth and then making your lunch, etc.? No, well that’s interesting because I didn’t either.”

However, my mind being an agile machine already figured out my morning in the order that is natural for me. You complete your morning in an order that is natural to you. That’s what the team is trying to do in an agile development environment – add value in an order that makes sense to the user.

My next question, “In life, did you have goals?” Sure you did. You wanted that degree, you wanted a fiancee, a family. Just like Epics are large features or initiatives for products, your life has some large features and initiatives, also!

Now my expansion on that approach…  Bruce Feiler (@BruceFeiler) helped me take that to the next level with his Ted Talk titled “Agile Programming for Your Family.”  I was currently blending a new family: myself with two children and my fiancee with two children (Ages 4, 7, 9, 12).  I decided to put this “stuff” I preach to the test.

I went to the local office supply store and for about $50 I was able to produce four boards for the kids’ rooms.  Keep in mind, I have zero craft skill.  For my four-year-old I used a picture-based board which she could understand, and more elaborate solutions for the older children.  Two examples are below:

Ireland's Board

Austin's Board

With this layout, it is so easy even a four-year-old can do it! If my youngest needs to make her bed, I move the magnet to the frowny-faced girl.  When she is done, she puts the magnet under her picture and if either of us approves, we will move it to our picture. If we do not approve, we explain why and move the magnet back to the frowny-faced girl. Now if I walk into a bedroom and their bed is not made, or their floor is dirty, I simply move the magnet to Not Done.  After a short time I get, “Can you come check my board?” from one of the children.

While we do not do daily standups, we have weekly retrospectives where we all sit on the floor and talk about the week.  What went bad, went well, and what could we improve on?  This is also a great time to congratulate someone or provide a family announcement since we have the children half-time.  The children also get a chance to have a voice and we have a positive environment for change.  The adoption of this approach has made a huge impact on our family.  The older children self-organize (a.k.a., tell on each other) if one of them is slacking; the younger children actually encourage each other and often help each other complete their tasks.  We were finally asked about allowance…

While we don’t like that word – and also like to instill life lessons – we did implement a flat salary that has additional commission benefits. If the children keep their boards up all week without too much parental encouragement, then they receive their salary.  If they go above and beyond the board, they receive a commission.  For example, maybe my nine-year-old vacuums the upstairs without this being a task.  He just realizes it needs to be done and does it.  We make a mental note of that.  Now this is where it gets interesting. During the retrospective we hand out the cash, in all Ones, of course.  We pass it out around the circle. If someone didn’t go above and beyond, they get to hold that extra money as they pass it around the circle until it gets to the rightful owner.  Are we driving behavior? You bet we are!  Positive behavior that if you want something in life, go get it!

While the salary and commission do not have that much to do with agile development, the approach provides us with a mechanism for other teachings which we would like our children to pick up.  So I have Bruce to thank for the success we have had. If you haven’t had a chance to see his talk, I have provided a link below.  I truly believe that agile development is a successful philosophy which any company or family can adopt and be successful!

Agile programming for your family – Bruce Feiler

 

 

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies | 2 Comments

Changing the Mindset of Agile Teams

Guest post by Venkatesh Krishnamurthy, delivery coach, author, advisor and curator with Techwell

Agile is not about practicing Scrum, XP or Kanban. It is a mindset that one needs to cultivate. It is not about doing a daily standup or retrospective but knowing the values/principles behind it. Most of the agile teams are interested in practices and very few are interested to learn the values/principles.

People resist adopting new values and principles as it expects a change in mindset of teams. Changing the mindset of agile teams is always a bit difficult. I have started believing that it is easier to change the people than their mind. The good news is, there are some tools and tips available to help in this journey of changing mindset.

Let me explain one of the tools with an example. A couple of weeks ago, I came across these two dustbins outside of our apartment complex.

venkatesh-dust-bins

As one could see, one of them a simple open cardboard box and the other one is a proper dustbin. Not sure why they had kept these two together. In the next few days, I noticed that people were throwing wastes mostly into the open box. However, the other one needed additional effort to open the lid to throw the wastes, which was left unused.

What I learned from this experience is, if you want people to follow ideas, make it easier for them to learn and use. Or else they will never change. 

Another case study is from one of my agile projects. The teams were using an agile project management tool which was not so user-friendly. Teams diligently added all the user stories and tracked them on a regular basis. However, when the need came to extract the key metrics like Velocity and Cycle times, the team had to write queries manually and tweak it regularly. They always resisted this manual, cumbersome process, which was time consuming as well. The teams always used to fall behind sharing these critical agile metrics with the stakeholders.

venkatesh-dots-user-cards

I suggested an alternate approach, which involved adding a dot on the user story cards after their daily standup until it is complete. It looked something like the one shown in the picture below for measuring the cycle times.  They used a simple sketch pen to put the dots on the cards.  This was so much easier, and the team loved it.  After this little change, they never resisted sharing the metrics.

Conclusion: If you want to change the behavior or mindset of agile teams, create an environment that is easier to navigate and use. The non-intuitive tools and processes could be a major blocker in the change journey of your teams.

About Venkatesh

Venkatesh Krishnamurthy is currently working as a delivery coach for a large financial institution in Melbourne, Australia. In the past, he has worked in different capacities from a developer, architect and as a scrummaster. He has designed some of the largest applications, led and built Cloud Center of Excellence, and has managed large-scale distributed teams of more than 150 people. Venkatesh is an author, Agile fellow, and Agile advisor for many companies around the globe. Check out his blog here.

Posted in Agile Adoption, Agile Benefits, Agile Methodologies, Agile Metrics, Agile Teams, Scaling Agile | Leave a comment

Three Agile Styles

Guest post by Allan Kelly, founder of Software Strategy in the UK

From time to time I feel sorry for those coming new to agile. I feel sorry because some of them expect to find agile provides a solution to their problem. For better or worse, agile doesn’t provide a solution but many solutions. The agile toolkit contains many tools which solve many problems in many contexts. But, like showing a customer software, the problems and context only become visible when solutions are seen.

For the last few years, I have found it useful to differentiate three different styles of agile. These styles are independent of any particular method: Scrum, Kanban, Lean, XP, etc. can be used in any of the three styles. Each style addresses similar – but not identical – problems within different contexts. The result is that the solutions, while similar, differ.

Iterative Agile:

The developers and testers are doing lots of good agile stuff: daily standup meetings, fortnightly iterations with planning meetings and retrospectives, small vertical stories and so on. Hopefully they are doing some of the technical practices:  Test Driven Development, Acceptance Test Driven Development, Behavior Driven Development, Continuous Integration and, perhaps, Pair Programming.

As a result, the teams are better.

But the team’s work is still driven by a big requirements document. Someone has set down in advance all of the features and functionality which the team is expected to deliver. The job of the team’s product owner (often a business analyst) is to salami-slice this document into small, vertical stories for the team to build each iteration.

The fact that the team can show a working product every two weeks is irrelevant outside the development team. The business and customers want all or nothing. They have little or no time to look at demonstration – indeed being expected to attend a demo may be seen as an inconvenience.

In Iterative Agile, requirements are turned into code via a series of iterations which are confined to the development team. The wider organization does not want to change. You hear people say things like, “Agile is a delivery mechanism.” They expect agile to deliver more efficient teams, fewer cost overruns, better predictability and meeting deadlines.

Project success – and it is still seen as a project – is defined by how much of the original document is delivered in the time allowed for the money budgeted. Project managers continue to fear “scope creep” and resist attempts to move away from the original requirements document.

Incremental Agile:

At first glance, this style looks a lot like Iterative. There is a big requirements document, there is a business analyst with a bacon slicer, the development team does iterations, and within the iterations is a lot of good agile stuff.

But in this model, business representatives, customers, users and more engage with the team. At the very least, review the software that is produced every two weeks in a demonstration. Feedback is accepted, some of the originally planned work changes, more work is added, but some is also removed. Hopefully the most valuable work is getting done first and the lowest-value work is falling off the end.

Better still, an incremental team may be delivering their product to live, and real users are using fresh software every few weeks. Hence, the business benefits early and value increases incrementally.

This also opens the door for the business analyst to perform post-delivery evaluation on what is built. This in turn allows the salami-slicing process to be better informed and calibrated to deliver more benefit.

However, there is still a requirements document and the team may still be judged on delivering everything by a predetermined date for a predetermined budget. Incremental agile potentially brings the team into conflict with project governance and thus creates tension in the organization.

Over time, the organization may start to adapt to the team. Success can be additive and others may start to change their working ways to fit with the team better – or even copy them.

Alternatively, the organization might kill the team! In fact, I believe in many corporate environments this is a more likely outcome. Incremental teams can be seen as problematic; they don’t stick to the script and they ruffle feathers. Unless they have a protector with sufficient authority and political weight, the team is at risk.

I have come to believe that in a large corporation, Incremental Agile teams are as good as it gets. It is hard to prove or disprove this belief and there will always be a minority who does better, but in a traditional corporate environment.

Evolutionary Agile can best be summarized as, “Don’t give me no requirements document!”

The development team is still doing all the good stuff. They are releasing to live at least every two weeks. The product owner will be more focused on reacting to change and delivering business benefit than delivering a document.

The wider business judges the team’s success not on how much software they have delivered against plan, but on the benefit they have delivered and movement toward some overarching goal.

There will still be a backlog of work to do, but it will start small and grow over time as the product grows. Much, perhaps most, of the backlog will never be implemented simply because the stories with the greatest benefit will squeeze out those with less benefit.

Indeed, in an Evolutionary Agile environment, this is how it should be…

Evolutionary Agile is most naturally at home in startup environments which need to react – pivot! – to survive. Inside the corporate world, the iterative style rules. Few corporations are ready to give up their faith in the big requirements document and forward planning.

In setting out these styles, I am describing what I find – not what should be. Few teams sit down and consciously decide to pursue one style rather than another. Each is a solution to a specific version of the problem: “How do we organize our software development?” within a particular context. And each context is loaded with history.

Having said that any of the three styles can be implemented with any of the agile methods, I do believe that Scrum tends toward the Iterative and Incremental styles while Kanban tends toward Evolutionary. My own Xanpan hybrid, with its planned and unplanned work model, tends toward Incremental.

Which is the “best” style? Well, I try to remain neutral. Each is a rational response to a context. Rather than say one style is “better” than another, I prefer to look at what the organization is trying to achieve and how it got to this point. Then I work to improve within the existing style – or perhaps, nudge the team toward a more appropriate style.

The Incremental style is probably the most common agile style of all. It might be seen as a step from one world to another; the best of both extremes; or perhaps the worst of both.

Yet, I find it hard to disguise my belief that Evolutionary Agile is in some sense superior, better, purer and truer to the original ideas of agile. I must temper my belief with a recognition that in some environments Iterative or Incremental approaches are more appropriate.

Indeed, one can imagine a spectrum with pure Evolutionary Agile at one end, and at the other end is traditional Waterfall development. Iterative Agile and Incremental Agile are just points alone the spectrum.

While I may want teams and organizations to aspire to Evolutionary Agile, it doesn’t really matter what I want. The challenge for teams is to position themselves at the most appropriate point on the spectrum and work effectively given the context of the wider organization within which they exist.

For many teams, simply moving from a poorly performing Waterfall model to Iterative Agile will be an improvement. One may hope they continue their journey along the spectrum, but if the wider organization is not ready to live in an Evolutionary world then the context is not right. And to do so would create more problems than it solves.

I find that these styles and the idea of a spectrum help me understand the world, as they provide the language to discuss it. I hope you also find them as useful.

Posted in Agile Adoption, Agile Development, Agile Methodologies, Agile Teams, Enterprise Agile, Scrum Methodology, Test Driven Development | Leave a comment