AgileHolland

Handling Your Team's "Rotten Apple"

Thu, 08 Jan 2009 13:47 GMT

Recently there has been an active discussion in the Scrum Development Yahoo Group about handling an "under-performing" team member. In the 130+ response thread, "Rotten apple in Scrum team", talk ranged from advice for the primary question, to talk of team morale and who manages it, to the classic debate of measuring individuals, to distinguishing whether a team is really a "team", and more. By Mike Bria

Манифест Agile-разработки ПО (Agile Manifesto)

Thu, 08 Jan 2009 09:26 GMT

Манифест

Мы находим лучшие подходы к разработке ПО, непосредственно участвуя в процессе разработки и помогая другим. В процессе работы мы пришли к тому, что для нас важнее:

Люди и их взаимодействие, чем процессы и средства
Работающее ПО, чем исчерпывающая документация
Сотрудничество с заказчиком, чем обсуждение условий контракта
Реагирование на изменения, чем следование плану

Авторы:

Кент Бек (Kent Beck)
Майк Бидли (Mike Beedle)
Ари Ван Биннекум (Arie van Bennekum)
Алистэр Коуберн (Alistair Cockburn)
Вард Каннингем (Ward Cunningham)
Мартин Фаулер (Martin Fowler)
Джеймс Греннинг (James Grenning)
Джим Хайсми (Jim Highsmith)
Эндрю Хант (Andrew Hunt)
Рон Джеффрис (Ron Jeffries)
Джон Керн (Jon Kern)
Брайн Марик (Brian Marick)
Роберт К. Мартин (Robert C. Martin)
Стив Мэллор (Steve Mellor)
Кен Шваубер (Ken Schwaber)
Джефф Сазерленд (Jeff Sutherland)
Дэйв Томас (Dave Thomas)

Принципы, лежащие в основе манифеста Agile

Мы придерживаемся следующих принципов:

Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.
Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.
Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.
Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им - они выполнят работу.
Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром - непосредственное общение.
Работающее ПО - главный индикатор продвижения проекта.
Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.
Важна простота - искусство увеличения объема работ, которых удалось избежать.
Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.

Материалы

При подготовке статьи использовались следующие материалы:

Веб-сайт, на котором размещен манифест http://agilemanifesto.org/
Русская адаптация (их текст вы прочитали выше)
http://agileconsulting.ru/wiki/Agile_Manifesto

Yin Yang Project Management

Wed, 07 Jan 2009 15:57 GMT

How understanding the balance inherent in agiles guiding principles can help project managers make the transition from traditional project management methodologies to agile.

Esther Derby: A Poor Performer?

Wed, 07 Jan 2009 12:52 GMT

Mark Levison has an interesting post in response to a Scrum Development discussion about "bad apples" on a team.

Before applying the label, look for reasons the person might not be performing. There are lots of reasons for a temporary dip in performance. Or, it might be a problem with the tools available, or the environment. It's very common to attribute problems with the system to the individuals (and vice versa).

Our own prejudices can get in the way. My friend Jerry tells a story about when he was a grader for a college course. His job was to read essays and grade them based on criteria. When he turned the grades over to the professor, the professor challenged one of the grades, an A. "You can't give this person and A," he said, "he's a C student."

Mark offers a quote from Linda Rising:

"In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice."

Mark advises:

So before we rush off to action on poor performers:

Stop, let go of preconceptions
Re-examine the person's role on the team
Listen/Watch - don't measure
Only if there is a problem - then solve it.

I agree.

Also see:

George Dinwiddie's Working Hard or Hardly Working, and my response.

and...
When is it time to move someone off the team?

Doing Agile After Layoffs

Wed, 07 Jan 2009 09:30 GMT

Part of a development team has been laid off, the team is down to four developers with a part time Scrum Master and no dedicated Product Owner. Is Scrum still applicable? What options are there? How does one adapt? By Mark Levison

Marc Evers: Principles of time management

Tue, 06 Jan 2009 17:42 GMT

In the previous entry, I wrote about the time management book Do It Tomorrow. This post is about the principles of time management that underlie Do It Tomorrow:

have a clear vision
one thing at a time
little and often
define your limits
closed lists
reducing random factors
commitment vs interest

Have a clear vision

Have a clear vision of your goals, of the things you want to do and the things you don’t want to do. A clear vision directs your priorities. Setting priorities is only meaningful between projects, not between tasks that have to be done anyway (’project’ is loosely defined here as an activity that leads to some desired result and that cannot be finished in one go).

Your vision is not something static: it will change over time. So frequently revisit your vision, to keep your priorities clear as well.

One thing at a time

Focus, focus, focus! Use for example timeboxing or working with a pair (like pairprogramming) to work in highly focused way. Don’t dilute your focus by having too many projects at the same time.

Little and often

Work on things frequently, in small bits, iteratively and increment, so that results grow over time. If you want e.g. to write a book or finish a Ph.D. thesis, work every day on it. Actually doing something and keep doing it is more important than the amount of time spent.

This works for writing, uncluttering your home or office, bookkeeping, and many other larger activities.

Define your limits

Creative thinking works better within clear boundaries. An example of limits is timeboxing your activities, e.g. using the pomodori technique.

Defining limits is also important for your projects: determine the boundaries (and frequently re-determine them) to get a clear focus of what you’re doing and what you aren’t doing, instead of being busy with a cloud of all kinds of vaguely interesting and possibly relevant stuff.

This week, I’ve started to make a map of all the projects that I currently have and that I want to take on this year. Being an independent consultant, I don’t have an organisational context that sets a lot of boundaries for me so I’ll have to set them myself in order to be effective.

Closed lists

A closed list is a list that has a line under it and that will not change. For every day, you make a Will Do list, a closed list with the stuff that came in the previous day and your recurring tasks. As the list is closed, it will only shrink when you’re finishing items from the list. This will give you a feeling of accomplishment at the end of each day, when all the Will Do items have been checked.

Anything that comes in during the day and that is not a real urgency, will be put on tomorrow’s list or below the line of today’s list. You’ll first finish all the items above the line, before doing the newly added things.

This approach enables you to plan most of the work you do, so you can work much less reactively and much less governed by self-inflicted urgencies. Your day to day planning will become more predictable and you’ll get early feedback when you’re structurally overloaded.

The Will Do list is limited by your daily processing capacity (so you will need to find out what it is), so you prevent backlogs from building up. If you get more work each day than you can handle the next day, you’ll have to either cut down on your commitments, make your systems more efficient, and/or allocate more time for the stuff on your lists.

Willem asked, what do you do when the telephone rings? It depends: you can answer the call, make a note, and take action tomorrow (unless, of course, it’s about your house being on fire). You can also decide that you won’t answer the phone during certain activities, listen voicemail later on, and get back to the callers the next day. It depends on the nature of your work and your preferences.

Another advantage of closed lists is that you don’t have to prioritise between the items. They all need to be done and if the list is limited by your daily processing capacity, it will be finished. Prioritizing doesn’t make sense for stuff that needs to be done anyway.

Working this way gives peace of mind and reduces waste: you don’t have to spend your energy making difficult decisions about priorities. Prioritizing is waste: it’s work that adds no value, but just increases the pressure on you! You’ll have more time and energy left for actually doing useful stuff.

Forster’s recommendation is to start with the least urgent things first. If work has to be done anyway, why not do it right away?

A bright, grand idea like writing a book is not something you can finish the next day. This becomes a project, a task that recurs (a little attention every day) until the work is finished.

Reducing random factors

By preventing most ‘urgencies’, you will reduce a lot of (self-inflicted) variability in your day to day work. Closed lists system make the underlying systems problems visible. You can’t eliminate all variability and randomness, but you can reduce them substantially, giving you more freedom, making sure your important things get done, and enabling you to handle the remaining randomness better.

Commitment vs interest

You can be interested in a lot of things, but you can have only a limited amount of commitments. It is important to know your commitments, as these provide a framework for your decisions. It’s like the pigs and chickens metaphor used in Scrum (chickens are only involved, but pigs are committed). A pig only has limited ham and bacon it can provide… (the pigs and chickens metaphor has its limitations, but that’s another story)

Principles of time management

Tue, 06 Jan 2009 17:42 GMT

In the previous entry, I wrote about the time management book Do It Tomorrow. This post is about the principles of time management that underlie Do It Tomorrow:

have a clear vision
one thing at a time
little and often
define your limits
closed lists
reducing random factors
commitment vs interest

Have a clear vision

Have a clear vision of your goals, of the things you want to do and the things you don't want to do. A clear vision directs your priorities. Setting priorities is only meaningful between projects, not between tasks that have to be done anyway ('project' is loosely defined here as an activity that leads to some desired result and that cannot be finished in one go).

Your vision is not something static: it will change over time. So frequently revisit your vision, to keep your priorities clear as well.

One thing at a time

Focus, focus, focus! Use for example timeboxing or working with a pair (like pairprogramming) to work in highly focused way. Don't dilute your focus by having too many projects at the same time.

Little and often

This works for writing, uncluttering your home or office, bookkeeping, and many other larger activities.

Define your limits

Creative thinking works better within clear boundaries. An example of limits is timeboxing your activities, e.g. using the pomodori technique.

Defining limits is also important for your projects: determine the boundaries (and frequently re-determine them) to get a clear focus of what you're doing and what you aren't doing, instead of being busy with a cloud of all kinds of vaguely interesting and possibly relevant stuff.

This week, I've started to make a map of all the projects that I currently have and that I want to take on this year. Being an independent consultant, I don't have an organisational context that sets a lot of boundaries for me so I'll have to set them myself in order to be effective.

Closed lists

A closed list is a list that has a line under it and that will not change. For every day, you make a Will Do list, a closed list with the stuff that came in the previous day and your recurring tasks. As the list is closed, it will only shrink when you're finishing items from the list. This will give you a feeling of accomplishment at the end of each day, when all the Will Do items have been checked.

Anything that comes in during the day and that is not a real urgency, will be put on tomorrow's list or below the line of today's list. You'll first finish all the items above the line, before doing the newly added things.

This approach enables you to plan most of the work you do, so you can work much less reactively and much less governed by self-inflicted urgencies. Your day to day planning will become more predictable and you'll get early feedback when you're structurally overloaded.

The Will Do list is limited by your daily processing capacity (so you will need to find out what it is), so you prevent backlogs from building up. If you get more work each day than you can handle the next day, you'll have to either cut down on your commitments, make your systems more efficient, and/or allocate more time for the stuff on your lists.

Willem asked, what do you do when the telephone rings? It depends: you can answer the call, make a note, and take action tomorrow (unless, of course, it's about your house being on fire). You can also decide that you won't answer the phone during certain activities, listen voicemail later on, and get back to the callers the next day. It depends on the nature of your work and your preferences.

Another advantage of closed lists is that you don't have to prioritise between the items. They all need to be done and if the list is limited by your daily processing capacity, it will be finished. Prioritizing doesn't make sense for stuff that needs to be done anyway.

Working this way gives peace of mind and reduces waste: you don't have to spend your energy making difficult decisions about priorities. Prioritizing is waste: it's work that adds no value, but just increases the pressure on you! You'll have more time and energy left for actually doing useful stuff.

Forster's recommendation is to start with the least urgent things first. If work has to be done anyway, why not do it right away?

A bright, grand idea like writing a book is not something you can finish the next day. This becomes a project, a task that recurs (a little attention every day) until the work is finished.

Reducing random factors

By preventing most ‘urgencies', you will reduce a lot of (self-inflicted) variability in your day to day work. Closed lists system make the underlying systems problems visible. You can't eliminate all variability and randomness, but you can reduce them substantially, giving you more freedom, making sure your important things get done, and enabling you to handle the remaining randomness better.

Commitment vs interest

You can be interested in a lot of things, but you can have only a limited amount of commitments. It is important to know your commitments, as these provide a framework for your decisions. It's like the pigs and chickens metaphor used in Scrum (chickens are only involved, but pigs are committed). A pig only has limited ham and bacon it can provide… (the pigs and chickens metaphor has its limitations, but that's another story)

Code2Plan, a Free Visual Studio Agile Project Management Add-in

Tue, 06 Jan 2009 05:29 GMT

Jesse Johnston and Denis Morozov created code2plan, an Agile software project management tool, as a beta Visual Studio add-in and released it for free. The tool also runs as a stand-alone application that can be used to track projects, iterations, user stories, features, tests, defects and builds. By Abel Avram

The Correct Ratio of Agile Testers to Developers? It Depends.

Mon, 05 Jan 2009 12:30 GMT

An long-standing question in the software development world is: what is the correct ratio of testers to developers? A recent thread on the Scrum Development list asked how agile impacts this ratio. The answer to the first question seems to be 'It depends'. The answer to the second question, according to Elisabeth Hendrickson, is that agile teams can do more testing, with fewer testers. By Chris Sims

The Rise of Lean

Mon, 05 Jan 2009 07:45 GMT

Will infoq.com have a "Lean" section in the near future? Given the recent rise in blogs, presentations and articles on Lean subjects, don't be surprised if, in 2009, Lean will be the new Agile.

Lean is a process management philosophy derived from the Toyota Production System that aims to provide more value with less work. Lean originated from mass manufacturing, but has successfully been applied in other industries such as health care, travel industry, and services. That means Lean can also be applied in software development.

Although Lean is becoming more popular in the Agile community, the views on what Lean is, differ widely. Martin Fowler tries to avoid the entire Lean vs. Agile debate by stating that they are equal. Although the idea of keeping Lean within the boundaries of Agile has its appeal, not everyone agrees.

Some see Lean as an improvement on Agile. Alan Shalloway from Netobjectives sees Lean as 'Agile in the Enterprise', referring to the 'value stream' thinking tool that Lean offers. In a Value Stream Map, the entire process of delivering value to the customer is studied and improvements are made based on the biggest problems in the stream instead of optimizing only small parts. In an enterprise environment this could provide a lot more reduction of waste than a regular Agile approach. Scott Ambler refers to the local optimization of Agile as silos, although he might not think of Lean as removing these silos.

Lean is also used to criticize current Agile methods such as Scrum. Tobias Mayer loosely quotes Marry Poppendieck in his blog claiming Scrum being "insufficient". This triggered a response by David Anderson; one of the most profound contributors to the current rise of Lean in software development. David presented Lean concepts at Agile2008 in his talk 'Future Direction for Agile', opening up Lean as a way to improve further on Agile.

For many, Lean will be used as a set of (thinking) tools that can aid in tuning current Agile practices. A perfect example is Corey Ladas's Scrum-ban approach; a way to upgrade the default Scrum task board using Lean tools. Given the rising popularity of that article, I predict many Scrum-ban boards will be implemented by current Scrum practitioners. I expect some case studies to appear on Scrum-ban at Agile2009. Thanks Olav Maassen, a strong proponent of Kanban, a new stage has been added to Agile2009 for these cutting edge Lean practices. For more information, have a look at an in depth example is use of Kanban in the gaming industry.

Although there are different views on Lean within the Agile community, they have one thing in common, they all adopt only parts of Lean. One cause is the limited amount of books available on Lean Software Development. Of course the Poppendiecks have written great books on Lean Software Development, but a community needs more than one source of information. Books such as 'The Toyota Way' and 'Lean Thinking' describe the original Lean principles. When one reads these books, it becomes apparent that some key Lean concepts are ignored in software development.

David Binnerts pointed out the concept 'standard work' missing from Lean Software Development. Lean defines standard work as: 'the current best practice'. Anyone performing the same task should follow the same procedure. This is the basis for 'Kaizen', the process of continuous improvement and refinement. Only with an established current practice can you improve that practice. Especially software developers have very limited experience with this amount of discipline and abolishment of variation. Perhaps David Anderson would want to to introduce this concept in software development using CMMI?

Dave Thomas and Alan Cooper describe the entire software development process more or less as a waterfall. According to Dave Thomas software is still hard to change once it is written, which makes Extreme Programming close to impossible for large projects. He claims the need for a design and architectural phase before actual implementation starts. This approach cuts the development part in two halves: the design and the implementation. Both this design and implementation phase would benefit greatly from a Lean approach. This is, however, not compatible to Scrum or XP and could be seen as un-Agile or labelled Big Design Up Front.

A concept like Standard Work doesn't seem to fit the XP/Scrum organic self organization of teams. Whereas Scrum does not exclude this concept, as David Anderson states, Scrum could be viewed as the current best practice on which a team can improve further. Scrum, perhaps similar to CMMI level 2, a good baseline for further refinement and expansion into all areas of practice and organisation.

I admire David Anderson and Corey Landas for their unconventional thinking. A lot of new Lean concepts and practices are ready to enter the software development community. I hope Lean will be embraced fully, including the hard parts that require great discipline. I crave a new view on software development and a long term vision. A few months ago at Agile 2008 I speculated on a new hype that could surpass Agile, however I never expected it to come this quickly.