Posts

, , , , ,

Agile – How to abuse it?

Many people have abused the term “Agility” by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:

Don’t document anything!

– The documentation that an Agile project produces is significantly different from what traditional projects produce. An Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.

Agile need to No planning!

– Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.

Just build something! (without capturing requirements)

– The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.

No control over budget or schedule

– Agile projects always operate within a “Time-Box.” That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, “We will deliver the greatest possible customer value within the project constraints!”

Developers come from wild west (doing whatever they want)

– The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.

If you see any of above signs in your team, it’s time to stop pretending and get real. Its time to seek help from an experienced agile coach. I would like to thank Alan Koch for sharing his thoughts.

, ,

New to Agile?

In short, agile and lean are general concepts, the former basing on Agile Manifesto and the latter on Toyota Production System. Then we have Scrum or XP, built over agile, and Kanban, built over lean, which are specific methods teams can implement, like Prince2.

Personally, I don’t treat agile and lean movements in a very orthodox way — they base on the same principles. So, to some point, they’re overlapping. Also, you will find teams mixing methods from both houses, Scrumban (a combination of Scrum and Kanban) being probably the most common.

If you wanted to position agile/lean methods somehow I’d say that:

  • Scrum is the closest to the old-school project management methods, although it doesn’t really deal with formal side of project management.
  • XP focuses on engineering practices and is generally programmer-centered.
  • Kanban is often dubbed change management framework as it doesn’t change the way team works on the day 1 and lets the process evolve over time.
  • As all three focuses on different things, it isn’t uncommon to see them, or their parts, used jointly.

If you want to learn more I’d start with such set of materials:

  • Introduction to Scrum on Mike Cohn’s site. If you want more on Scrum Mike Cohn’s site is a good place to find also more advanced stuff on Scrum.
  • Once you know what Scrum is I’d strongly recommend Henrik Kniberg’s and Mattias Skarin’s minibook Kanban and Scrum – Making most of both which is great in terms of describing Kanban but has a lot of referrals to Scrum.
  • For more advanced stuff on Kanban I’d recommend Limited WIP Society articles (topic for my next blog).
  • Good kick start on XP can be found on Ron Jeffries’ site.

In terms of books as a kick start, I’d recommend:

  • Mike Cohn’s Succeeding with Agile for Scrum
  • Kent Beck’s Extreme Programming Explained for XP
  • David Anderson’s Kanban for Kanban

If it is too much of a hassle to read these books and digest then contact us and we may be able to help you.

, , ,

Agile Learning and Seeking Knowledge

India’s Mars Mission

2013-11-05 09.23.07

A proud moment for every Indian as rocket lifts off from Shriharikota (South India). A massive step towards learning about red planet. This news prompted me to consider the current and future role of learning activities undertaken by people and organisations. Learning is acquisition of new information through practice or experience[1] and it occurs in response to a need or problem.

2013-10-25 18.55.17-1

During my MBA lesson at MBS Manchester, professor Norman Longworth describes the stages in human learning as “Information Ladder”. According to the ladder, a learner moves through the following progression to construct ‘wisdom’ at the highest level from ‘data’ at the lowest level:

Data -> Information -> Knowledge -> Understanding -> Insight -> Wisdom

Whereas the first two steps can be scientifically defined, the upper steps belong to the domain of psychology and philosophy.

According to Sherry L. Willis, a renowned researcher from US, long-term learning activities is the ability to acquire and retain relevant information and to solve problems. Problem solving involves assessing the present state, defining the desired state, and finding ways to transform the former to the latter. Decision-making refers to the evaluation of possible solutions and the selection of one for implementation[2].

A major difference between experts and novices is in their possession and use of two forms of knowledge: declarative and procedural knowledge. Declarative knowledge involves knowing what facts and information are relevant in solving a particular problem[3] .It is one’s knowledge of the subject matter. Experts have the ability to select quickly the most relevant information for a particular problem, obviating the need for a more exhaustive and time-consuming search through their declarative knowledge.

Procedural knowledge represents the individual or organization’s understanding of how to go about solving a particular problem—how declarative knowledge relevant in a particular situation can be combined to produce a solution[4]. Often the procedural knowledge involves performing a set of operations or following an algorithm.

Individuals and organizations that are new to Agile and Lean may spend much time developing or discovering a plan as they go about solving a problem. An agile expert is quick to develop an appropriate plan to use relevant information and solving a particular problem. The expert “plugs in” the relevant information to the plan or script which helps you to gain knowledge and apply with greater efficiency.

Please contact us and see how our experts can help you and your organization with learning Agile and Knowledge Management .

REFERENCES

  1. Howard and Howard, 1997
  2. Reese and Rodeheaver, 1985; Reitman, 1964
  3. Anderson, 1985; Chi, 1985
  4. Anderson, 1985; Chi, Feltovich, and Glaser, 1981
  5. Rogers, 2000