We are warning you! Our Agile Architect is in a pretty cantankerous mood. Read this at your own risk.
So you're running a big complicated enterprise-scale operation. You're doing agile at the team level and now you are ready to tackle enterprise-scale agility. You take your first steps to introducing an enterprise-scalable agile framework. Oops! You may have just made a big mistake.
What makes Enterprise Agile different from plain ol' ordinary agile? Our Agile Architect returns with a series of columns exploring what we can gain from enterprise agility.
If you think this is going to be an article on evil product owners and how they just want everything, you're going to be disappointed. Our Agile Architect explains how 'Greed-Accelerated Development 'is the completely achievable desire to want more from your work than just the immediate benefit while not paying any additional price for it. Bwa Ha Ha Ha!
Safety is an important ingredient in any agile retrospective. If team members don't feel safe, they may not be candid and honest with their input, negating the effectiveness of the retro. Our Agile Architect shares some of his techniques for measuring and maintaining safety.
There has been a lot of misinformation about the nature of DevOps and its relationship to (Big A) Agile. Our Agile Architect explains why DevOps is an important component of (little a) agile, plus offers the top five DevOps misconceptions dev teams often have.
Quality assurance has long been an important component of an agile team. But times change. The introduction of new capabilities like ubiquitous cloud computing, containerization and microservices changes the way we think about QA. Here's how.
Agile is not a hard science like physics or chemistry. There is no fundamental theorem of agility. But practices in agile act along empirical scientific principles in that experimentation can lead to measurable results, reproducible across teams in similar conditions. So why does each agile team feel compelled to rediscover this again and again?
Our Agile Architect recently celebrated his 10 year work anniversary and uses this as an opportunity to look back and see how agile has changed over the last decade.
Things agile developers want to tell you but won't.
Our Agile Architect talks about the benefits of T-shaped people in agile and the dangers of stressing broad knowledge and participation over deep expertise.
Our Agile Architect discusses strategies for working with a product owner that can't hold to a decision long enough to see it realized.
It is difficult to solve a problem if the problem itself cannot be stated clearly. How does one "create a compelling user experience that will double our sales" or "build me something really cool"? Our Agile Architect discusses why the first problem an agile team must often solve is to define the problem itself.
After tearing down code branching strategies in a previous column, our Agile Architect demonstrates a different way to support parallel software development that fosters greater agility and speeds development.
Our Agile Architect shares a success story of extreme agile taken not just to the edge but over it.
We have the best software development tools in history. Why are our developers so afraid to refactor? Our Agile Architect explores how powerful code management tools can lead to powerful problems that inhibit agility -- and what you can do about them.
This is the completely true and not at all exaggerated story of how I, the Agile Architect, saved the Earth from complete and utter destruction. I'm sure there's an agile lesson in there somewhere.
Agile software development can be stressful. Recognize it, admit to it, deal with it, fix it.
Agile proponents promote self-organization. But what does this really look like? It turns out that achieving real self-organization takes...organization.
Who needs respect? It's more important to be right! And to be right, you have to be heard. So go ahead and talk over your colleagues. It's for the betterment of the project. Am I right?