Agile Software Development

9 February, 201618 February, 2016

Hit Rock Bottom? Maybe Now You’re Ready for Agile

One of the things I enjoy most about my work is meeting other Agile practitioners and coaches and sharing war stories. Recently I was at an Agile Coffee with people who had various experience with Agile, ranging from complete neophytes to folks with many years of experience. The topic chosen was “What are the preconditions for a large company to be successful implementing Agile?” – a very pointed, yet valid, question to be sure. All of the answers were ones that one might expect; support from upper management, learning culture, etc. except for one. The lone unobvious answer was provided by someone whose opinion I respect. I was somewhat surprised at the time and it has reverberated in my mind ever since, “one precondition for a company to be successful in an Agile transformation is they have failed miserably and have hit rock bottom.”

The term “rock bottom” is most commonly used by folks in NA and AA (Narcotics Anonymous and Alcoholics Anonymous). I found the following definition of rock bottom on a website for alcohol addiction:

… often used to describe a point … when they are finally willing to seek help. Things are now so bad for them that it is impossible to deny their problem anymore. Hitting rock bottom may result due to a particular event, or it can be a slow decline over time. This is a subjective term because some … will be willing to suffer a lot more … than others.

I first came in contact with Anonymous groups through my work in healthcare (nearly a lifetime ago when I was a licensed Health Care Administrator) and have more than one commented on how Agile transformations remind me of some of the twelve steps – with the first step being to admit one has a problem.

So when my friend mentioned that a good indicator for agile transformation success was a company had hit rock bottom I knew exactly what he was referring to. In this particular case he used the examples of the FBI Sentinel Project and Healthcare.gov website debacle. In both cases, it wasn’t until each was a total disaster that Agile was actually tried with any seriousness and rigor and in both cases the results were amazing.

The total spend of these [two] failed [Waterfall] attempts to replace the ACS system was $597m and wasted 10 years. The Agile project, which is now delivering a solution, will only cost $114m for a three-year long project.

In another recent talk I went to on Agile a gentleman explained how Agile helped with an ad agency. He was only brought in AFTER the agency blew millions on a website that never made it to production. After losing millions I would guess this agency hit “rock bottom”. The good news was that Agile was able to help them to change and allowed them to produce high quality software with a much better time to market (than never).

In my agile coaching practice I have had more than one conversation with enlightened management that has acknowledged our Agile transformation wasn’t working as good as hoped and, barring a complete meltdown, most folks were happy to continue along a non-optimal path. In fact, relative success is a particularly sticky barrier to change as people often confuse the ability to get something done with the ability to get something done optimally. Bill Gates has often remarked, “Success is a lousy teacher. It seduces smart people into thinking they can’t lose.” Sometimes what we mistakenly call “failure” is a much better teacher. Sometimes the lesson is more important than the perception of relative success or failure.

Just this morning I was listening to my local NPR station as they were having a fund drive. Like many others, I couldn’t wait for the drive to be over so I could no longer had to feel the shame and guilt of being a “free rider”. Fortunately, it was the last day of the pledge drive and my mind was only half listening to the chatter of the announcers when they introduced Shankar Vedantam who does segments on the Hidden Brain (which I enjoy immensely). His topic was why people donate (or don’t donate) to pledge drives. He talked about humans’ tendency to pay more attention to emergencies and crisis than what is important. Being the last day of the pledge he hoped what was merely important (donating) would now also be given the status of an emergency because time was running out.

My mind went immediately back to the concept of “rock bottom” and why this is one good indicator of where Agile can be successful. Sometimes it is only when we hit rock bottom that the importance of being Agile begins to align with the immediate crisis of having to be Agile. It is then, and unfortunately for some, only then when Agile gets the attention and focus it deserves. It is my hope companies realize becoming an Agile organization is essential to their long term survival (at least in organizations that rely heavily on software development), seek the help they need to transition and actually carry out the transition before they hit rock bottom. In the meantime, if you have hit rock bottom (are you listening Yahoo!?), please seek out Agile help.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

26 January, 20161 February, 2016

The 3Ps of Agile Software Development

I am often faced with explaining the various aspects of Agile to people new to Agile and I have come up with a very simple way to remember (and explain) Agile. I present to you now the “3Ps of Agile Software Development” with the hope you find this useful to your own understanding and an aid in your ability to explain Agile to others.

Philosophy

“The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.” – Albert Einstein

At the core of Agile is the Manifesto. A few years back, I even took the time to create business cards that contained the four values and twelve principles. When I heard people say that this is or is not Agile, I could hand them a card and say, “This is Agile.” This is where I start in explaining (and training) Agile because without the philosophical underpinnings one is most certainly lost. I couldn’t give an exact number, but I do know that a high percentage of companies trying to move to Agile are unable to fully embrace and promote the philosophy behind Agile. I wrote my first book, Understanding The Agile Manifesto: A Brief & Bold Guide to Agile, because I have witnessed firsthand the struggle companies are having with adopting the Agile Manifesto. I have seen companies rewrite the Manifesto to omit or change things that they find too difficult to embody and watched good people punished for having the temerity to post the Manifesto at their workplace. The philosophy is the base upon which the other two Ps rest.

Process

“This strange dichotomy, this agonising gulf between the ought and the is, represents the tragic theme of man’s earthly pilgrimage.” – Martin Luther King

It is not enough to have the basic philosophical understanding of Agile, we must find ways to embody the principles. There have been a number of ways to embody this philosophy over the years. Take for example, Scrum. Technically it is a framework, but it contains ceremonies (actions) that allow us to realize the Agile philosophy. Why do we do retrospectives? Because the last of the Agile principles state, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” While Scrum has claimed a high level of mindshare, there are numerous other processes and frameworks that also help organizations embody the philosophy of Agile (Kanban, DSDM, Crystal, etc.). In fact, Agile’s history is one of empiricism with people “uncovering better ways of developing software by doing it.” This means it was actually Process (and the 3^rd P) which came first. It is Agile Processes that help us to realize the philosophy of Agile.

Practices

“Practice does not make perfect. Only perfect practice makes perfect.” – Vince Lombardi

Sometimes when we classify things, people can certainly disagree with our classifications, but when I explain the term “Practices” I am referring specifically to software development practices that are done within the processes and frameworks. It is into this category that I would put things like Extreme Programming (XP) practices as well as something like BDD. What separates these things (which could be argued to be processes) is there more technical nature and the needed expertise of software development professionals (developers and QA) to implement. Processes are things that embody the Agile philosophy which any intelligent individual could understand and facilitate. For example, though it might be optimal for a scrum master to have a development background, one could be successful as a scrum master without it. On the other hand, one could not be successful in performing code review or test driven design (TDD) without knowledge of coding. Why do agilests do BDD? Because through BDD we can realize (among others) the principle that states, “Business people and developers must work together daily throughout the project”. It is Agile software development practices which also help us to realize the underlying Agile philosophy.

While any system of classification subject to interpretation, I have found that speaking to the 3Ps of Agile Software Development has provided a simple and understandable way to introduce people to Agile. If you get a chance to present this, please let me know if it helps you as well.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

9 September, 20131 February, 2014

Two Time-Management Techniques to Aid Agility

Originally published on ScrumAlliance.org

With Agile as a philosophy and Scrum as a framework, ScrumMasters are sometimes on their own, left out in the cold when it comes to specific tactics. While I heartily recommend such practices as BDD (behavior-driven development), continuous delivery, and so on, there happen to be some simple time-management practices that I have found to be beneficial for almost all of my teams that have chosen to adopt them.

Team time facilitates collaboration

As every Agile practitioner knows, collaboration is essential to succeeding in Agile so that all parties can discuss the work that needs to be done. To increase collaboration, most of us facilitate grooming sessions with our teams to do things like pointing, writing acceptance criteria, and breaking down epics.

But there is one challenge many of us face: how to effectively schedule and ensure participation.

From my experience, one useful way is to establish “team time” every day right after the daily stand-up. Every day for my teams it takes the form of 45 minutes after the stand-up, which allows us appropriate time to sprint plan, sprint review, retrospect, backlog, story groom, and maybe tell a joke or two.

One of the major benefits is that every team member knows when they are going to meet in perpetuity, so they can more easily find productive time unburdened by a great number of ad hoc meetings. It also lends a very nice rhythm to their day! Since this (and my other technique, outlined below) is agreed to by the team and its efficacy discussed in retrospective, it’s a great example of how a team can maximize collaboration. I have had multiple teams use this technique over the past few years, and I honestly can’t recall one that did not feel it was beneficial.

“Office hours” allow team members to focus and find flow

Veteran ScrumMasters know that individual team members should not be scheduled for eight hours a day. In fact, most know that getting five good hours in a day would make for a productive day indeed! Besides, if you are using the team-time technique discussed above, then you’re starting an eight-hour day with only seven. But here’s the big question: How can I make sure I can get in those five productive hours a day?

In order to ensure that individuals get the needed focus needed to achieve a flow state, one that is necessary for good concentration and coding, most of my teams use “office hours.” These are time slots, decided upon by the team, when they are available for productive work only (e.g., tasks assigned during sprint planning). They will usually schedule a two-hour block in the morning and another three-hour afternoon block in Outlook (if you don’t use that, then you can use a real calendar! No, just kidding).

Not only does this eliminate disruptions but it is compatible with pair programming or other team interaction work when needed. As with team time, it is rare for a team to try this simple technique and then choose to go back to, as one team member put it, “scheduling chaos.”

Stronger together than apart

To summarize, using team time as discussed is an excellent way to facilitate engagement while also ensuring that the team’s rhythm is unbroken. As well, office hours provide a great, chaos-free environment for the team to buckle down, since the time blocks are clearly outlined. While each technique, in isolation, is beneficial for many users, I have found that team productivity soars when the two are fused together.

To see what this looks like in action, take a look at my example spreadsheet below. This will give you a starting point for your own implementation of these two techniques (and maybe jog some of your own inspiration!). I hope that this makes the Agile road easier to travel, because believe me, the journey is worth it.

For additional reading, here are two articles I recommend that touch on this subject:

If you have any questions, feel free to reach out with commenting below or with social media. Thanks for reading!

– Larry Apke

28 February, 20131 February, 2014

Want a Quick Agile Win? Try Office Hours

When you are an Agile Coach you sometimes must resign yourself to the fact that it will usually take team members awhile to get it and victories can be few and far between. One thing that I can recommend for a quick win and something that has worked well for me on multiple occasions (when it could be implemented) is something that I called office hours. I can only assume that I am not the one who invented this, but it is something that I “discovered” independently to solve the issue of resources being pulled into unproductive meetings when I needed them to be on task for our stories.

Continue reading “Want a Quick Agile Win? Try Office Hours”