Discussion: Agile Principles

Discussion: Agile Principles
Joe Burroughs

Joe Burroughs

Many people are frustrated by uncertainty and complexity in their jobs. I use Agile principles to provide clear and simple strategies so that you can win at work!

Can we improve on the Agile Principles?

The Agile Manifesto and Principles were originally penned in February of 2001. That is a long time ago, especially when one is talking about digital transformation and modern product delivery. So it begs the question can we improve on them or reword them in some way to increase their current value or meaningfulness? 

Let’s refresh our memories and take a look at the current version and then we can consider ways to improve them.

The Original Agile Principles

The agile principles, really the foundation of that agile mindset. This is what puts you into that growth mindset. That feeling that you can really deliver an be flexible to do so. 

Now again it comes from that original Agile Manifesto and it is very software focused, but if you take the key pieces out, you can see how it can be applied to manufacturing human resources marketing, you name it. Anywhere where you’re delivering value. 

Our highest priority is to satisfy the customer through early and continuous delivery. Early and continuous delivery deliver smaller, increment faster, and continue to do so. 

Business and delivery work together. In other words, business people and developers must work together daily throughout the project. 

Working software again, software lens is a measure of progress. This would be delivered value working product. Add if you’re looking at marketing whatever it is, you’re delivering a unit of value, and that unit of value being delivered is the measure of progress. 

Maximizing the amount of work not done, simplicity, in other words, is essential. 

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

Build projects around motivated individuals rather than building a team around a project. You build the project around the team. You give them the environment and the support they need and trust them to get the job done. 

The sponsors, developers and users should be able to maintain a constant pace indefinitely. So instead of thinking of it as starting a project, working through the project, and then closing the project. It’s more like the work is fuel and the team is an engine producing thrust or forward moment. So the the work flows through and you have your foot pegged to the floor. You’re maintaining that constant pace indefinitely. 

The best architectures, and requirements and designs, emerge from self organizing teams. The 2020 scrum guide is changed this to self managing teams, but the view there is really at these enterprise organizations. It’s difficult to allow self organization within a large enterprise. In other words, “Hey Bill hey Jane. Hey Jeff, what do you guys want to work on?” “Well, let’s see if you can build a team around that.” It just doesn’t really really work that way in the real world. But it does at some levels. If your team happens to work in an innovation department or research area of a large organization, you do have the opportunity to self organize a lot, and within whatever team structure you have, you can organize to some degree that level of flexibility is going to be very influential. The more flexible your team allows itself to be, or is allowed to be by leadership. The more novel and the more innovative your team’s going to be able to be. Consider this self managing teams and think about that flexibility that you have. 

Deliver working software frequently, in this case deliver value frequently from a couple of weeks to a couple of months with a preference on the shorter timescale. What can you actually deliver that would be valuable to the customer in a couple of weeks? 

The most efficient and effective method of conveying information to and within a development team is face to face conversation. Again, the agile principles out of that older agile manifesto. Face to face gives us a lot more context. Think about this for a second. How many classrooms have you sat in learning what words mean? How to structure a sentence? Reading comprehension, maybe English language writing theses all this different stuff? How many hours do you think you’ve spent learning language? In a formal setting? And the answer is probably significant! Now, think about how many hours you’ve learned nonverbal communication in a classroom setting, and you probably have a little bit. Maybe facial expressions, some gestures that you’ve been taught relative to your particular industry, or even some general ones, maybe how to read if someone’s upset as a child. You got some facial expression stuff and some body posture, and you were always told in classes to make eye contact and how to give a, you know, presentation. These types of things, but if you add all those hours it’s probably less than 12 hours, probably far less depending on your profession. And yet human beings trust nonverbal information far more than we trust the words that are coming out of other people’s mouths. That’s why Zoom. And all these other video channels, Teams from Microsoft, Teams, Webex… That’s why they are so popular. We want to see the person speaking to us so that we can get as much nonverbal as possible. Are they having trouble Making eye contact? Is their rate of speech, and that’s something you can pick up over the phone there pitch their tone, their rate of speech that gives information away? How sure are they they’re going to be able to deliver this week, or how convinced are this is the right path for us to explore? Face to face conversation in our day and age can be video calls, can be phone and and video as well. So whatever you can do to increase the amount of nonverbal communication, the stronger your communication is going to actually be. 

Continuous attention to technical excellence and good design enhances agility. That means clean code and great customer experiences. Putting the customer first because they’re baked into the process, you’re going to get feedback from them every two weeks to two a month, and you don’t want negative feedback. So good design both went in terms of code in terms of logic of the process and in terms of actual design, the user experience all of those contribute to enhance agility. 

And at regular intervals, the team reflects on how to become more effective than tuned and adjusts its behavior accordingly. This is known as inspect and adapt. What have we done? What can we do better? It’s not negative. What did we do wrong and how can we prove it? Even what did we do well? And how can we improve that? So fantastic way to move the ball forward.

How could these principles be improved or updated?

Given that these are 20 years old what would you address, change or update to increase the value or make these more relevant?


Joe Burroughs

Sharing is Caring!

We are working hard to grow our audience and you can help! Please share any content your find valuable or interesting.