photo by Qole Pejorian

Baby steps is one of the principles behind the eXtreme Programming and other agile methods. It is, namely, performing changes in small steps on every level, be it implementing a feature, changing the database structure or just coding a couple of methods. The ideas behind this principle correlate well with not programming by coincidence and usually baby steps are implemented with test-driven-development based techniques.
Levels

• On the coding level baby steps mean changing the code in small bits and verifying that it still works after every small change. Often it means using test-driven-development, running a local set of unit tests after every change and periodically running the whole test set.
  

Innovation games are a special type of activities designed for embracing the innovation by helping people to collaborate and discuss in a form of playing a game. These games are a way more useful and more interesting, than any traditional requirement workshop based on reviewing the requirement document proposal. Innovation games are one very clear example of applying the Individuals and interactions over processes and tools principle. Buy a Feature game explained in detail in the Luke Hohmann's book* is one of the most frequently used in the course of agile software development whenever there is a need to prioritize a reasonable amount of not very well understood features.
The Rules

Sometimes there are customers who "generally" agree to using Scrum as a software development process, but fail to fulfill the product owner role. What do you as a team do then?
Product owner responsibilities are the ones that virtually any customer has got. Product owner is responsible for deciding what features are the most profitable for him, for controlling the return on investment, for accepting or rejecting the work results - in essence he is responsible for making money out of the development effort. I've never seen a customer who would not like to to decide on what is the most important for spending his money on.
What often happens in the case of not collaborating customer is one of the following:

• product owner simply does not have time to participate the sprint reviews every two weeks, or maybe he does not believe that his attendance will be worth the time spent
• product owner cannot freeze his wishes for even the sprint period of time and gets new priorities every day
• product owner is used to contracting in the waterfall manner, got used to that it is pointless to review the mid-project documents and does not really know that Scrum will make him a usable product after just a handful of sprints

Solutions

Scrum is the adaptive and flexible software development methodology. The possibility to adjust it according to the team preferences and organizational culture make Scrum implementations look differently across the organization. Some teams like packing the estimation session into a separate day, some like doing a little bit of estimation during every sprint planning; some teams have 5 minutes long sprint reviews, some have to make their reviews day long in order to let all the stakeholders express their opinions.
Scrum process schedule can and should be adjusted according to the retrospectives held. Therefore, it is not that important to start with the perfect schedule, it will anyway be adjusted. However, it can save some time if we you start with something that works for many teams out there. Here a couple of more-or-less standards schedules to start with.

In four days after the desires for the agile-aware C++ IDE were posted on AgileSoftwareDevelopment.com, Michael Feathers, the author of "Working Effectively with Legacy Code" posted his own set of the refactoring-related requirements for the IDE.
Have a look

z_post_title="Refactoring tool requirements";z_post_category="IDE,Michael Feathers,refactoring,tool";

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

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.

z_post_title="Earth travel";z_post_category="Bas Vodde,course,CSM,Helsinki,Martian,Scrum";

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.

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.