Having lived through numerous attempts to build software embracing the concepts behind the agile manifesto, I feel there are three large categories folks fall into when talking about agile principles.
A friend of mine asked me what is going on with all this touchy-feely people and personal growth stuff – “What’s it got to do with Agile?” My answer: everything! Here is a diagram of my Culture Reboot Roadmap.
A model of the predictable stages of agile team competency helps managers and leaders define the benefits they’re getting, determine the benefits they really want, and plan next steps. Join Diana Larsen in an exploration of ways leaders can use the model to analyze and monitor progress of Agile competence in teams.
Boyd, with his colleagues, have brought about many changes and had to fight hard against the Pentagon’s resistance to change - so typical of large bureaucratic organizations.
Did you have a good Mother's Day? This GitHub developer's mom is certainly interesting... Since day one, we've faced an unique engineering problem: making terabytes of Git data always available, either directly or through our website.
The Temenos container provides a powerful mental model for understanding and improving relationships with others. The same notion can be used to understand groups we are part of as well as our relationship with ourselves.
I believe that every company deserves working software that can be delivered on a consistent cadence. That cadence needs to be shorter than 30 day) and they need to get continuous feedback that is fed back into their backlog.
The purpose of this post is to explain why building culture adapters around at team or group is a good idea. It is important for me to revisit this topic from my book and conference presentations since I have learned something new and wanted to share it. All but the last section is an excerpt from my book.
"Developers work in sprints, estimating tasks in JIRA as they go. Sprints last three weeks, including planning, development and testing. I have been tasked to produce burndowns to keep track of how the Dev cells are doing.”
The classic tale of a year-long project finally being delivered only to discover it doesn’t meet the needs of the customer sounds ridiculous in the days of short iterations and customer collaboration but I’m guessing we are still a long way from delivering what’s really needed effectively. So what’s stopping us?
If you’ve ever had any involvement with an Agile project (whether it was “pure” Agile or not), you’ll likely have encountered the beast which is effort forecasting and analysis. This drives the initial estimate of the amount of work which your team thinks it can deliver within a given period.
The seeds of backlog decay are often sown in the very willingness of an agile team to be adaptable. Urgent tasks are dealt with as they arise, and backlog items are pushed back to make way. Can anything be done to stop a Product Backlog from becoming the "Land of Forgotten Dreams"?
When I feel empowered, I can get work done, achieve my coals, do my best, be more effective, effect change, or do anything!
A simple list of bullet points to check for when you are writing tests. Always try to improve your naming, mocking, refactoring, and picking scenarios.
This is the latest iteration of my Agile Program and Portfolio Management deck. Take a look and let me know what you think!
One of my readers asked a question about the Urgent queue and the relative ranking of my ever-growing left hand column. How did I determine what to do, and what was the rank of each?
In this post I am sharing workshop results on how to understand the readiness of the leadership to undertake organizational transformation such as the intentional upgrade of the cultural operating system. It is partly a checklist and partly a diagnostic tool to understand current perceptions.
Based on how we think about rules, we can roughly divide ourselves into 4 categories: Upholders, Questioners, Rebels, and Obligers. Self-awareness being a good thing, I thought I’d share and think about how these types effect our ability to get shit done.
ExperTelligence introduced IB in 1986. We took it up to neXt to show Steve Jobs – the rest is history. In 1988, Denison Bollay built a much more dynamic interface tool, in which the interface was fully modifiable as the program was running.
Many development shops have made the leap from RCS, Perforce, ClearCase, PVCS, CVS, BitKeeper or SourceSafe to the modern Subversion (SVN) version control system.
Any interface develops in cycles. Someone comes up with a new interface, users start bringing in their feedback — that’s the stage of step-by-step improvements. One has to rework some parts of the functionality and mix in new features gradually, without having people learn from scratch.
Last month InfoQ carried an update on the use of retrospective dialogue sheets. The use of these sheets continues to grow and I continue to receive good feedback.
User-journey tests are a form of BusinessFacingTest, designed to simulate a typical user's "journey" through the system. Such a test will typically cover a user's entire interaction the system in order to achieve some goal. They act as one path in a use case.
I previously wrote about my Sublime Text setup. Well, Tuts+ has published a quite nice Sublime Text tutorial showing most of Sublime’s features. Regardless of whether you’re a Sublime Text enthusiast or not, you should definitely take a look at the tutorial.
Mythbusters is enormously popular with technical types, and it's fair to say that it has earned something of a hallowed position in nerd culture. It's certainly a common topic at the water cooler for many in the IT business. So is there something in their approach to busting myths that resonates with modern software development practice?