Agile Layoffs

Agile processes often enter the organization from the grass roots – from the developers appreciating useful practices and insightful low level managers seeking for ways to help their subordinates. However, if things progress well, at some point the top management might buy the idea of delivering incremental software faster, than the competition, and declare “we are going Agile” or even “we are going AGILE“. While the top management support is something to appreciate, there is still a number of issues to be aware of, when restructuring mid to large size organizations. One of the most important changes is the potential career ladder restructuring.

Whole team mindset

The thing is that while all the agile processes value specialists of any kind ( DBAs, architects, testers, UI designers, etc.), the cross-functional team is a corner stone of all the agile methods. This cross-functionality means whole team commitment to the goals and consequently it means the need for team members to cover each other. Architect is expected to help the UI designer, when UI guy is overloaded. Tester is expected to discuss the testability of a feature right, when it is being designed. Experienced specialist is expected to help the technical writer, when documentation is the current bottleneck. And all the mentioned things are to happen not once a year, but several timer per iteration (several times per 2-4 weeks) at the very least.

Career path break

Now imagine an architect or “team lead” who invested ten years of his life into becoming a good architect or lead. His progress was typically measured by how little he has to touch the code (“no time for coding” as we usually say), how many windows are in his office, how precise his documents are, how well he manages the task list and how well he commands his team. Now suddenly he is called just a “team member” without any extra authority, has to do testing, documentation and the team is declared being “self-managing”?!

What’s worse, there is no project manager role in most of the agile processes. No single project manager role at all. The responsibilities of the project manager certainly don’t go away, but are moved into several roles:
– self-managing team,
– product owner – the one who prioritizes the features, but is not allowed to say how to do them and cannot change his priorities every couple of days (though can do it freely every 2-4 weeks)
– facilitator (Scrum Master in Scrum, Coach in eXtreme Programming). This facilitator role has absolutely nothing to do with command’n’control, but more with helping the team to resolve conflicts and with helping it to remove obstacles (e.g. he helps with arranging a projects room, buying new monitors, etc).

Conflict of interests

Looking at the transformation level expected, I doubt that the high job-graded specialists and especially the project managers could have a lot of motivation for going Agile. Even if we introduce changes gradually. If I was PM, I would probably think twice before going to really support the Agile thing. Even if being a product owner or Scrum Master is a lot of fun AND money, there is still a lot of hard learning on the way.

I am not sure about the possible resolution for this conflict of interests. Maybe it is exactly the moment when the HR team can extend a helping hand to the whole organization by exploring what other companies did in similar situations and helping to clarify the career options in the world of Agile.

Your careers

Dear readers, do you think there is a career conflict between the traditional situation and the agile stuff? Was or would your career be in danger? Should the project manager be worried?

Earth travel

Some “products” from the Scrum Master course by Bas Vodde.

Today we were building a poster for a Martian travel agency. Since the course is held in Helsinki, no surprise we decided to offer some tours over Finland.


That’s what out first 8 minute sprint day ended with. Not really shippable, but if we had to release it next minute, we could probably deliver it.


After the second day our prototype evolved to something more shippable. Still without the prices yet.


After the third day our proxy-Martian product owner was happy with this poster, so we were done. We still had ideas and things to make better. We definitely would do it in the following days, but from this moment whenever we would be forced to release, we would have a ready solution.

Agile-aware C++ IDE

A colleague of mine lately asked me what would be the most important C++ IDE features for supporting the agile software development. While agile processes are more about people and interaction, than about the tools, a decent tool support certainly makes things easier. Here is a list of things I would value in the agile-aware C++ IDE in the order of decreasing priority.

1. Command-line repeatability
Agile methods see the high levels of automation of a ‘mechanical’ and repetitive tasks as a relief for the developers and help to reduce errors. While IDEs are important the ability build, test and deploy software in automated manner e.g. on a continuous integration server is of no smaller importance. Therefore, everything IDE has to do in order to produce the software that is DONE has to be identically repeatable from the command line. Or at least as much as possible

2. Unit testing support
Test driven development is virtually an indispensable part of the agile team toolbox. There has to be support for easy test case creation and execution. In particular, I’d like to see (in the order of decreasing importance):

a) Ability to switch unit testing frameworks. There are many frameworks out there and many teams build their own variations. It would be good to have the ability to plug various things in and maybe parse the report back into IDE. Naturally this ability would require from the framework developer to write an adaptation layer, but the IDE should have a place to plug this layer to

b) Ability to add/remove/rename tests in “one click”. It has more to do with the framework used and how well it utilizes macros, but it would be good to have a tool support (wizard or browser based) for it. Disclaimer: I am working with Symbian OS. A number of limitations doesn’t allow writing the test name in one place only. I constantly have to synchronize strings in at least three places for every test. Non-Symbian programmers might not value this item that high.

c) Ability to run all or some of the tests in “one click”. And see the results, of course.

3. Refactoring support
The more the better. A good prioritisation principle could be to follow the Martin Fowler’s Refactoring book table of contents (Amazon link). The earlier the refactoring is mentioned, the more useful it typically is. My personal top list (once again in the order of decreasing importance) would be:

a) Extract method

b) Rename method

c) Extract class

d) Duplicate observed data. Though I am not sure if this one can be automated

Other requirements
What would your desires for the agile-aware C++ IDE? Did I miss anything important or did I request anything useless?

Agile Software Development one pager

Agile software development is a set of core values. Iterative, incremental software development methods (ASDM) are based on these values. If I had to boil the overview down to the three most important items, these would be the following:

1. Iterative planning and releasing
ASDM recognize that it is rarely if ever possible to accurately plan software in advance. Customer priorities change, competitors force to release something early and even the best requirements obtained by pure thinking and analysis cannot be as good as the ones refined after seeing a running program. Instead of doing a single planning/analysis session for a couple of years ahead, ASDM plan iteratively as often as once a month or a week, refining the plans, schedules and priorities iteratively. It includes the ability to release the bug free software whenever market conditions require.

2. People-oriented processes
While ASDM recognize the value of documented requirements, they also recognize that such an uncertain thing as not yet existing software is best developed when a lot of human communication is involved. ASDM are based a lot on building a team spirit, having developers work face to face with testers, analysts and even customers. If a thing can be discussed and solved without a document, than it should be done without (or with minimal) bureaucracy.

3. Engineering practices
To make the above items possible there are certain engineering practices that are not strictly required, but recommended. Most of them tend to directly support the above two items. Test driven development and heavy amount of automated testing help to produce code that is always ready to release and that is easy to change if customer priorities change. Big charts and informative workspace help to share the project information instantly. Continuous integration helps to make sure that the code is always in a good shape. Pair programming allow for the fast knowledge sharing and for always having an extra pair of eyeballs seeing the code. Etc., etc.

Pointers to deeper intoductions
1. Scrum in five minutes (pdf) – One of the most popular agile methods put simple. Scrum is more of a project management method and is less concentrated on the engineering practices
2. Introduction to agile software development (pdf) – Similar style ten-pager
3. Extreme programming: A gentle introduction – an introduction to the eXtreme Programming (XP), one more popular method. This one is more focused on the engineering and communication practices, than on the project management

See also the Power of Limited Forecasting

Business benefits of Agile methods

Agile methods significantly differ from the traditional waterfall-like methods. Agile teams don’t need a half a year of requirement analysis and design before the coding phase, most of the tests are written by programmers and are automated, customers are asked to participate, try live software and provide feedback frequently. All these peculiarities as well as inability to commit to the concrete set of deliverables early sometimes make agile methods look fluid and unpredictable – something not valued by the business people.

However, agile methods have a reason for not committing to the end result in the beginning of the project. And the reason is a simple fact – despite all the possible analysis, it is virtually impossible to predict the final desired content in the beginning of the project. It is well known, that during the course development both customer wishes and customer business environment often change a lot and initial plans and requirements are not relevant up to the point, when much less, than half of software features are relevant. No thoughtful and profound analysis can produce as good requirements as one can iteratively get from the customer feedback on the already running software.

Agile methods recognize the poor ability to plan software one year ahead and approach the problem by building the software in completed, finished and ready for usage blocks starting from the blocks of the highest value to customer. The frequent “completeness” of software gives a significant business advantage of, namely, agility. Whenever the customer desires or financial situation change, the development course can change accordingly. Whenever the release is forced (e.g. by the competitor) to be made, it can be done. Whenever it is discovered that developers got customers desires wrong, the corrective action is applied the next month.