First for the background on Agile Practice.  In February 2001 (while I was finishing my undergrad at Ball State University), 17 people got together at a ski lodge in Utah to “talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto.”  

Fast forward a few years, and it was sometime in 2007.  Where I was working at the time, we had a Lean Six Sigma Black Belt.  She encouraged me to look into this whole “Agile thing.” So the first book I stumbled across was by Mike Cohn – Agile Estimating and Planning.  The overarching concepts about how to plan and estimate work into manageable chunks, then execute just made sense to me.    

So over the next two to three years, I consumed as much information about Agile practice as I could.  But more importantly (unbeknownst to my team at the time) I constantly tried the different techniques I was reading about.  My main goal was to put my learning into practice, the concept of “shu.”

The philosophy of Shu-Ha-Ri within Agile practice was first introduced to me by Alistair Cockburn while reading his book “Agile Software Development.” After reading his book I was also fortunate enough to see him speak at the Agile and Beyond Conference in 2015 on this very topic.

Now I am over ten years into my Agile journey. While I feel as though I have moved to the “Ha” level (future posts coming on that), but I am still learning each day. So to get us started let’s dive into the traditional wisdom or values that define Agile, and I will share some thoughts or experiences on each.

Individuals and interactions over processes and tools

It can seem strange that a concept rising from the software development world speaks to people interacting, rather than simply following a process.  Let’s face it, by and large software teams are typically introverted or seen as “shy.” So how does a concept which hinges on these introverted people being social actually work?

In my experience I have observed first hand that taking the time to get to know the development team personally begins to open them up to conversations.  All to often, their quietness is observed as “disengaged.” However, it can simply be an individual actively listening and learning prior to offering suggestions.  Allowing for the individuals to be themselves and slowly encouraging the interactions between the team creates a space where collisions occur. Teams are then capable of pushing the boundaries of creativity and innovation.        

Sure, processes and tools can keep projects predictable.  But is that what we want? Or would we rather have end results that solve problems in the best ways possible?  If your organization values innovation over strict process, then a focus on individuals and interactions can create an environment capable of transformation.          

Working software over comprehensive documentation

If you are unsure where to start with Agile, there are many schools of thought.  Often you hear “setup daily stand ups.” While I think stand-ups can be a solid way to get started, where I have seen the light bulbs go off is when you create a feedback loop that showcases small wins early and often.

Sponsors and customers buy into what the development team is doing when they experience the project growth along with the team.  Creating detailed specs to then have a sponsor or customer sign off on, without understanding them, doesn’t move the team closer to the eventual goal.  In contrast. Having the end user interact with what is being developed as early and as often as possible will create a product that meets or even exceeds the needs when it is launched.  

Therefore when I am asked, “We want to use Agile methodologies, where do we start?”  My advice is simple. Create the ability to share progress with your end user, or customer, or sponsor on an every other week basis.  Or every three weeks. Or Monthly. Whatever the best cadence is for your work.

Let’s look at a quick example based in web facing software development.  Start by creating wireframes or design concepts early in the project. After you review these, mock up a screen or two.  After that incorporate the backend functionality. Working this way brings the decision makers along from the beginning. It also creates that feedback loop along the way, allowing for small adjustments.  

So the key is to not worry about having things perfect.  That is the entire point, they shouldn’t be. This is because it is too early to know how to best solve the need.  Really the key is to create a safe space for teams to showcase work and gather feedback. This allows for small shifts to be made as teams learn.

Customer collaboration over contract negotiations

Let’s take a project focusing on developing something that the end user really does not understand.  How do we expect the 50-100 page statement of work to be something that offers value to the customer.  To that same point, when you develop something that ends up not meeting their needs, do you really expect to take out that document and convince them that you followed the contract therefore they should be happy?

My hope is that you have started thinking, “well no, that is not a good experience.”  But to further illustrate my point think of two scenarios from the consulting world. Decide which will make more money in the long term.

Scenario A:  $100k project, everything is defined upfront, the dev team develops, it delivers on everything in the SOW to a T, but ultimately does not solve the end customers goal.  

Scenario B:  $50k project, starts by focusing on a small scope, which progressively solves all the customers immediate needs because they are collaborating every step along the way.  This early success results in another project. Then another. Then another…      

Sure, the quicker money is scenario A.  You get more revenue, and quicker. But, scenario A is likely more difficult to create long term lasting value.  Now, if we consider scenario B we have made less up front, but we have created a very happy customer. We have also built the foundation of a relationship.  Sure, the future revenues are unknown. But can we agree that they are likely greater than $100k over the life of working with this customer?

More importantly.  You have now created an advocate for your organization’s services.  Furthermore, folks in organizations talk to folks in other organizations.  This happy customer now brags to his network about the great work you did. Voila, your next project comes in, and the next, and so on.  Pretty soon, you have built a relationship with a wide range of clients and that initial $50k you “missed out on” has now grown over $200k-$300k in revenue.  See where I’m going with this?

Responding to change over following a plan

I have been a project manager on hundreds of projects over my career.  Some big, some small. Now if I were to venture a guess, I’d say 50-60 percent of these projects were traditional waterfall projects.  With these projects came gantt charts, ugh!

The sheer amount of time I have spent building a project plan, with dependencies, and ultimately inaccurate estimates is hard to think about.  And with all of these project plans, there is one thing which occurred each and every time. My initial plan fell apart when we learned of our first change!  

In contrast, when we look at the many flavors of agile nearly all of them utilize strategies of progressive elaboration.  We create clarity as we learn. We don’t expect to know everything upfront because we have not learned anything yet. So for the purposes of this conversation I am going to look at a Scrum.  

With Scrum we capture an idea when it is purposed, placing whatever we know at the time about it in a ‘story’ that sits in the backlog.  Then when we get to defined times in our project lifecycle – for instance sprint planning – we take that story and elaborate on it. We better define the description.  We ensure it is a SMART deliverable. That means it is Specific, Measurable, Attainable, Realistic, & Timely. We also give a quick, relative estimate for the work against the rest of the items in the backlog.  With our last focus on creating an understanding of what ‘done’ means for this story.

Now sure, this seems like a lot.  However, look at it this way. Would you rather do this to 5 or ten “requirements” at a time?  Or should we sit down as a group before we do any work, or learning, and define hundreds of requirements?  Chances are that if we take an approach of “eat the elephant one bite at a time” our team is able to identify the best way to work based off learnings along the way.          

A few common misconceptions of Agile    

Many of the detractors to the agile movement have a similar piece of feedback.  It goes something like, “how can there not be a plan.” Or “if we don’t have a contract, how do we know what is agreed to.”  In my conversations with these folks, the typical question I ask is, “have you read the last part of the manifesto?” Then I get a somewhat bewildered look.

If they were to really digest the last paragraph, it really wraps up the idea of Agility.  

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

So yes, there is value in a plan, but maybe just something with the key milestones.  Of course we need a contract if it is a vendor to client relationship. However, get the big rocks defined and work out the rest through collaboration.

Secondly there are the 12 principles.  These are often overlooked. But I believe these are best used by teams who are already working in an Agile environment, but feel like some things are missing or not working.  In my experience the most common is the idea that:

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

I’ve had multiple teams who feel like they are pushing too hard, or not able to keep up.  When this happens I’ve had to have that tough conversation with the sponsors. I lay out that a reasonable pace that delivers on time and with quality doesn’t have to include long hours.  Initially teams may deliver a lot of work. But teams burnout and work completed actually goes down over the long run.

As for my last concept, which is maybe the most important.  Keep in mind that Agile is a mindset.  Agile is not a cure.  It is not a process. It is not magic.  Agile is a way of thinking. It is a way of organizing.  It allows teams to grow through learning and creates a safe environment to stumble, but ultimately leads to growth.     

In conclusion

I have been and will continue to be a huge proponent of Agile practices.  Even before I knew what it was called, or knew the concepts that group of 17 people defined.  Truthfully I was already executing its practice. Human nature tells us that focusing on learning and adjusting as we go will more times than not lead to success. Especially when compared against exhaustive definition up front.

My hope is that this was informative, and that you will come back to this blog for more articles in the future.  I’m excited to dive deep into some agile concepts (more “shu” elements) and share some of my experiences (some “ha” elements). In the meantime, if you have questions or requests for future topics.  Reach out via my website or leave some comments below.  

The post Agile Practice: The Core Principles with my two cents (shu) appeared first on The PF Group, LLC..