You are hereFeed aggregator

Feed aggregator


Online Scrum Training

All About Agile - Thu, 06/23/2016 - 10:04

Over 80% of software projects in the world today are run using the Scrum framework. Big companies sometimes offer their own training programmes, but often Agile Scrum Masters take courses from one of a growing number of registered training companies. Every now and then I am asked to look at online training for Scrum and recently I had […]

The Retro Game

All About Agile - Wed, 06/15/2016 - 00:24

Learn more about transforming people, process and culture with the Real Agility ProgramThe Hunt for Better Retrospectives The rumours had started to spread, retrospectives at our organization were flat, stale and stuck in a rut. The prevailing thought was that this was stalling the pace of continuous improvement across our teams. In truth, I wasn’t … Continue reading The Retro Game →

The post The Retro Game appeared first on Agile Advice.

4 steps to solving issues in projects

All About Agile - Wed, 06/08/2016 - 17:31

In many different projects and organisations, I’ve seen people struggle with techniques on how to solve issues without creating huge issue registers that weigh down the project and takes an inordinate amount of time to manage, resulting in the actual problems often not getting the attention they deserve. There are lots of agile techniques for […]

Splitting User Stories

All About Agile - Fri, 06/03/2016 - 10:19

Learn more about transforming people, process and culture with the Real Agility ProgramA common challenge faced by inexperienced Scrum teams is related to splitting Product Backlog Items (PBI) so that they are granular enough for development. The INVEST model is a good way to test whether Product Backlog Items are well-written. I – Independent N … Continue reading Splitting User Stories →

The post Splitting User Stories appeared first on Agile Advice.

Achieving Collective Purpose

All About Agile - Wed, 03/30/2016 - 04:00

Teams are cross-functional - containing all skills necessary to define, build and ship the new features. The teams are aligned to producing value to the business rather than to the abstract purposes of providing excellence within a functional silo. This not only gives the team a laser-focus on adding value to the business.

Agile Change or Adoption Always Starts with Why

All About Agile - Wed, 03/30/2016 - 00:08

Your organization has decided to become more “Agile.” Why? As we learned in a previous blog post, “Because Our Competitors Are” is not a valid – or sensible – reason. Before embarking on a change, adoption, or improvement program, you need to know the rationale behind that decision. So… why Agile? A traditional approach to answering this question might see the executive team going off-site for two to three days and holding a workshop where they decide why they should be Agile, then design an adoption strategy, and then summarize the whole thing in a few sentences to be sent out in a memo. Typically, large-scale change initiatives have a lot more ceremony, more meetings, and more setup than this. However, there are several key failings, including that they involve only a select few executives in the envisioning and decision-making process, and they attempt to plan for the long haul. There are dozens of examples in our industry of failed change efforts that have cost billions of dollars and proved that this approach doesn’t work. At Nokia, Stephen Elop issued the famous ‘burning platform’ memo in 2011, and yet two years later the company was sold to Microsoft. In 2013 Avon had to write off $125 million[1] of work that built an enterprise software implementation which drove representatives away. This was change that failed to help the very people it was intended for. These and other failures involve some combination of the following: Why – The “Why” isn’t understood by most of the victims of change. Strategy – The “Strategy” created by the executive group doesn’t make sense to all of the people doing the work. Ownership – People at the edges of the system (who do most of the work) feel no ownership of the change. Connection – The strategy doesn’t appear connected to the problems that the people at the edges of the system are experiencing. Improvement -The strategy appears to improve the lot of the executives, but not of the doers. Culture – The change doesn’t fit the organization culture. Leadership – Top level is asking for change but doesn’t appear to be involved in making it happen. To be effective, Agile organizational change needs to… well, involve the Organization! Not just the executives who have made the decree, often without fully understanding what the goals of the change are. This shouldn’t be a quick decision made at a two-day corporate retreat. It needs to be an ongoing effort to figure out the “why” collaboratively and share it effectively, being mindful of some essential ingredients. We will address those ingredients in the next several blog posts. Avon’s Failed SAP Implementation A Perfect Example Of The Enterprise IT Revolution – Ben Kepes: http://www.forbes.com/sites/benkepes/2013/12/17/avons-failed-sap-implementation-a-perfect-example-of-enterprise-it-revolution Image attribution: http://photodune.net/

Refactoring: 4 Key Principles

All About Agile - Thu, 03/24/2016 - 16:35

Learn more about transforming people, process and culture with the Real Agility ProgramI believe in refactoring.  The Agile Manifesto holds that The best architectures, requirements and designs emerge from self-organizing teams. The quality of our software systems depends on refactoring.  In fact, I believe that the only way that an organization can avoid refactoring is … Continue reading Refactoring: 4 Key Principles →

The post Refactoring: 4 Key Principles appeared first on Agile Advice.

Simplicity

All About Agile - Mon, 03/14/2016 - 08:52

In 201x, the global financial markets collapsed. Reason: mortgages were given to people who couldn’t afford them. This debt was then repackaged and sold to banks and other institutions as good debt. (“The Big Short” by Michael Lewis is an excellent indictment of this time). However, the bigger question remained. Why didn’t the financial regulator system catch the problem early, while it was still small? The answer? Complexity. In “The Dog and the Frisbee” (pdf), Andrew Haldane, Executive Director Financial Stability at the Bank of England, explains all the things a dog would have to know and understand to catch a Frisbee: wind speed and direction, rotational velocity of the Frisbee, atmospheric conditions, and gravitation. It might require a degree in physics to know how to express the control problem involved in catching the Frisbee. Yet dogs, without physics degrees, do this everyday. They obey a simple rule/heuristic: “run at a speed so that the angle of the gaze to the frisbee remains constant”. Empiricism and Simplicity. Agile works because it is an Empirical process using constant feedback to update both the work itself and the way we work. Haldane goes on to show that the financial regulatory system evolved from something simple that many people at a bank could understand, to something only a few people could understand. Eventually it became so complex that no one person understood the system as a whole. The earlier regulatory frameworks worked well in part because many people understood, and therefore many people could spot problems early, before they got too complicated and large to resolve. As we deal with ever-larger organizations, it’s tempting to say that this increase in complexity is okay because we’re larger. But if financial crisis taught us anything, the answer should be no. The bigger the system, the more important it is to use simple control mechanisms, simple feedback loops, and simple measures that can be understood by all. Decreasing complexity – not increasing it – has to be at the heart of all of our decisions. And coupled with that has to be the ability to respond quickly and change appropriately.   Image attribution: damedeeso, via photodune