Category Archives: Back to the Basics

This a series of posts on the basics of current Agile methodologies. Specifically it covers the Agile Manifesto.

More Than A Process

Imagine being tasked with learning to play jazz. Working the scales. Memorizing songs. Over time you would develop a level of talent regardless of passion. You would probably even get good enough for gigs with a local bar. This would probably be good enough to fulfill the task of learning jazz. It wouldn’t get you to the level of Louis Armstrong though.

Sun Saxophone Means Jazz Music And Acoustic

Stuart Miles – www.freedigitalphotos.net

Attempting to move your team to Agile is the same. Put the proper processes in place. Follow the rules. Over time a new pattern of work develops, one that is more Agile-like than the previous one. This new paradigm plateaus. It’s probably different enough than what was done before that everyone looks and says “yep, we’re Agile now.”

Over time the management that wanted the team to go Agile is going to get frustrated though. This new paradigm, it’s not what she wanted. She was promised continuous improvement. She thought the team would become high-performing. She was expecting to have a product to market more quickly, and more relevant to that market when it arrived. Something went wrong.

This is not a process problem. In fact, evaluating the teams process against the rules of Scrum, Kanban, SAFe, or whatever agile process was chosen is likely to result in their process passing with flying colors. The problem is that Agile is more than just a process.

Continue reading

Back to Basics: Responding to Change

Plan A B Buttons Shows Decision Or Strategy

Stuart Miles – FreeDigitalPhotos.net

Agile, adjective. able to move quickly and easily. The final value pair focuses on the “Agile” part of Agile Software Development.

Responding to Change
over
Following a Plan

If we cannot evolve our plan over time then we are not Agile. This value is not about constantly changing for the sake of change though. Agile practices value the ability to change as new information is discovered. Continue reading

Back to Basics: Customer Collaboration

Young professionals business people discussing seriously in their meeting with documents over white background.

photostock – FreeDigitalPhotos.Net

We started our look at the Agile Manifesto by pointing out that Agile starts with people. The next value pair continues this thought.

Customer Collaboration
over
Contract Negotiation

After all, customers are people whereas contracts are legally binding documents. A contract is important. Getting it properly negotiated up front is something that we cannot ignore, but the time we spend collaborating with our customers is so much more valuable. It’s more valuable to us, and to them. Continue reading

Back to the Basics: Working Software

High Angle View Of Working Adult Female Doctor Stock Photo

imagerymajestic – FreeDigitalPhotos.net

The next value pair starts fairly easily with working software.

Working Software
over
Comprehensive Documentation

 While there are nuances that can be debated over it doesn’t take long for the act of debating them to devolve into little more than meaningless mental exercises. Changing this from “Working Software” to “Complete Products” may help when trying Agile in non-software environments.

The second half of this one, comprehensive documentation, this is the one that most people miss the meaning of when looking at Agile. This one could be debated for a long time. Unfortunately the only generic “right” answer for what it truly means is “it depends.”

Continue reading

Back to the Basics: Individuals and Interactions

Engineers discussing in front of computer.

Serge Bertasius Photography – FreeDigitalPhotos.net

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

Individuals and Interactions
over
Processes and Tools

This is how the Agile Manifesto starts. Not with a list of acceptable practices. With a statement that people matter. Specifically that they matter more than the process and tools that we use to get value. Continue reading

Taking Agile Back

I’ve seen some noise lately that appears to have started gaining momentum in February. It seems like it is still low on the signal to noise ratio, but it is a strong signal. It is starting to be pushed by thought leaders in Agile. Even some that have effectively been involved with Agile since before the manifesto. It has not yet reached critical mass, but I think it could.

I was not part of the early days of Agile. While the basics of Agile make just as much sense to me as to everyone else I was not involved in software development and project work until around 6 years ago. Before that I was CIT.

For the few projects we were part of back then we had smaller support roles. They were generally for setting up specific hardware/software and not conducive to Agile methods and practices. In retrospect we ran our team in a matter similar to Kanban, but without any formal process guidelines or documentation. Of course, even back then I was experimenting with improving our process through ticketing systems, deployment tools, and remote assistance – but I digress.

Since joining the Software development world 6 years ago the team I have been on has always been responsive to our customer. We have generally had a fast feedback loop for addressing problems and providing improved functionality. We have been able to work directly with key stakeholders. We have dabbled in improving our process as allowed by the organization.

We have not subscribed to a particular Agile methodology and forced it upon ourselves. We have not conformed to match what a consultant told us was the right way to do Agile. We haven’t, until the last year, even used the word Agile to describe what we do or how we do it.

In that context I may not look like the ideal candidate to be part of a movement about taking Agile back to the ideal that was imagined by some 13 years ago. That may be true, but taking Agile back isn’t just about the past. It’s about the future. I have immersed myself in Agile for a little over a year now. While I may not be a good representative of the past intent, I am part of the future. I may not be one to explain what Agile was supposed to be, but I am here to help shape what it could become. I am part of the movement to take agile back.

Read more at the following links:

Tim Ottinger
On http://notivago.org/
Curtis Cooley
Twitter
Google+

I’ve also written about similar problems before. My Agile is not Scrum post is probably the best example right now. I am also working on a series of posts I’m calling Back to the Basics which I hope will stick to the proper spirit.

Do you feel the current state of Agile is where it should be? Should we be working to “take it back?” How about “move it forward?”

Back to the Basics: Tensions to Manage

Before getting into the main value sets of the manifesto I wanted to take a moment and cover an important line that still manages to get overlooked by some.

That is, while there is value in the items on the right, we value the items on the left more.”
– Agile Manifesto

This line resonates with one of the biggest takeaways I have had from Andy Stanley’s free monthly leadership podcast. The concept is one of a problem to solve versus a tension to manage. Continue reading

Back to the Basics: Agile Manifesto History

Currently one of the hottest trends in software development is implementing Scrum. Scrum is a specific framework that, while predating it, adheres to the Manifesto for Agile Software Development (the Manifesto). This is not surprising. Ken Schwaber and Jeff Sutherland were two of the seventeen people whom came together and created the Manifesto. They had formally established Scrum as we know it today six years prior. The problem I see is people don’t understand why they implement Scrum or why Scrum has the roles, meetings, rules, and artifacts it does. The best way I know to start this dialog is with the Agile Manifesto.

This is the first part of a monthly (approximately) series of posts where I look into the Agile Manifesto. As Agilists this document is something we should be able to talk at length about. This is my attempt to break it down and remind us why we coach the behaviors we do whether in Scrum or not.

Continue reading

Back to the Basics: Prologue

“Fundamentals are the building blocks of fun.” – Ray & Molly (Dakota Fanning & Brittany Murphy), Uptown Girls 2003

If you haven’t seen the movie I forgive you. The quote is used twice. The first time by Ray (pre-teen girl) to justify herself (to Molly – her 20-something Nanny) spending a lot of time doing the same basic dance move over and over again instead of just having fun. The second time is by Molly to explain why she is taking an entry-level job in the fashion industry when her resume suggests she could skip ahead to a mid/high career level position. There are times when I read forums and blogs online where I feel as if Scrum is that higher level job or the more advanced dance moves. The problem is that successful Scrum should build on a Manifesto and Principles.

While reading a blog post by Mario Moreria I felt he may have found part of the root cause.  I have pointed out the danger of Agile being seen primarily as Scrum in previous posts. That post and my own thoughts inspired me to explore the heart of Agile. This week I am starting a series of posts that will go over what I consider to be Agile basics based on the Agile Manifesto and the twelve principles used to uphold it. Continue reading