Replenishing mind

Escaping from the tunnel vision of Scrum this week 🙂
Well, actually I don’t think the teams I work with are that tunneled. Still having a rest on a sunny beach is one of the best ways of refreshing the mind for me. Does it work well for you?

P.S.
This post is published by the automated scheduler, I am going to try not using internet as much as possible during this week.

(Picture courtesy of chicadelatele @ flickr)

Scrum at Yahoo and Google AdWords. Short summary


Short summary on the Jeff Sutherland’s story about how and why Scrum has been taken into use by Yahoo and Google AdWords.

Yahoo story
1. At some point Yahoo was a lot of “organic” company. There were many small teams with power to do pretty much anything with rather little discipline present.
2. They needed more structure and consultants gave them 300 pages long heavyweight process. Everybody hated it and it did not really work
3. They saw Scrum as a possibility to go back to their roots, while still having some structure in place. Nowadays a lot of new product development is done with Scrum at Yahoo

Google AdWords story
1. In 2001 there were quite many managers at Google. They tended to tell smart people not to do this or that. So Google got rid of those managers
2. Then there used to be many organic teams of three people with rotating leadership. About 160 teams reported to a single person – it was quite ok since teams didn’t wait to be guided. Still business-to-business applications needed more customer input, than consumer apps. Google especially mentioned localization issues – many things had to be consistently translated into many languages
3. Scrum appeared to be some kind of a compromise. Scrum hierarchy is as close to the organic groups as possible, but still has some structure and allows for easily seeing the high level picture and priorities. Scrum allows AdWords group for having a leadership driven organization with some rules.

Do you know how agile processes were taken into use by some other large organizations?

Weekly Agile Reading. Pack 3

Manually filtered top of the most interesting writing published since last Saturday. Of course, most interesting from my personal point of view.

Top writing of the week

  1. We’re live! (a success story) – An exciting success story of an XP project that resulted in MicroPlace. The critical success points listed.
  2. Trading off agile principles and practices – Dave Nicolette on the Valtech’s experiences with sacrificing some agile practices in order to support the more important ones.
  3. A very non-lean ER experience – Lean Blog reports on the awful visit to the emergency center. It is not exactly about the agile methods, but a very special story explored from a lean perspective (the agile methods are based on the lean manufacturing principles).
  4. Automating tests vs. test-automation – Google Test Engineering Manager tells about how they perform testing on various levels of the system.
  5. Those wacky agile zealots are at it again – Dave Nicolette’s fascinating allegory on a software product development.

See also

If you happen to encounter another interesting content published since last Saturday, please, post links in the comments.

XP Practice: Slack

Slack is one of the primary Extreme Programming practices, i.e. is one of those that can stand out and bring value on its own. Slack is a practice of of including in every plan a number of tasks or user stories that can be dropped if team runs out of time. The reason for including slack is to be honest and transparent about the workload estimation. Software production is always a new product development and every estimation is namely an estimation. Even if the team plans in detail for one iteration only, in most of the cases there is still some uncertainty and having slack is only about explicitly realizing it.

There are some variations of how slack can be used. Some teams prefer agreeing that some storied taken into iteration are considered droppable-if-needed. Other teams vise versa consider it useful to leave some “free time” in the iteration and agree which small stories could be included if everything went well and team really had some free time. There is also a possibility to fill the slack space with important, but not urgent technical tasks such, as major refactorings, unit testing script upgrades, etc.

Links

This page is a part of the Extreme Programming overview

How to make acceptance testing agile

I wrote about Acceptance Testing earlier and why it is a very important tool for agile development. In this post, I will talk about how we can make acceptance testing really agile. Actually, it’s nothing more special than making Acceptance Testing a part of your Continuous Integration (CI) (an XP Primary Practice). Continuous Integration is the practice of merging, building, and testing code on a continuous basis (almost instantaneous basis). Cruise Control is one of the most popular frameworks which allows you to implement CI.

Solution

Ok, so back to the topic. How do you integrate acceptance testing into a Continuous Integration cycle? Of course, to do so, you need to automate the acceptance testing. There are many frameworks available on the Internet for automating acceptance testing. Some are specific to a technology, while others are more general. The one I want to recommend is Selenium. Using Selenium, you can acceptance test your ‘web-based’ applications against a variety of platforms and browsers. Follow the above link to read more about Selenium. It is an open-source software and relatively simple to use.

Considerations

There are some points that you need to consider while employing Selenium or any other acceptance testing framework. And the choices you make depend on your situation. You can integrate Selenium into your CI cycle. If you use Cruise Control, then you can write scripts that automatically call and run Selenium test cases for your application with every build. So, here are the things to consider:

  • If you make the acceptance testing as part of your continuous build cycle, is it causing your agility to suffer because suddenly every build cycle is taking much longer? This can happen if you have a large number of test cases. This may not be noticeable in the beginning but as your code base grows, you can run into very slow build times.
  • One way to do it is to run the acceptance tests manually. But this may not work because your team will not get acceptance testing feedback with a lot of regularity; this defeats the purpose because ideally you want quick feedback so that you can correct the error before moving on. This may also be the case if you schedule these tests using some external scheduler because then you will not get a feedback upon every build.
  • Another solution is to trigger an independent running of these test cases whenever there is a build cycle initiated during the CI process. This allows the build to complete quickly and still you will get acceptance test results for every build.
  • A third solution is to only include certain tests in the CI cycle and run the full test case suite independent of the development cycle. This allows you to keep your important test cases within the CI cycle.

Depending on your situation, you can choose any of the approaches above; or even create a new one of your own. How do you automate your Acceptance Testing? What approach do you use? Do you face the problem described above?

Alternative XP – Courage, Respect, and Energized Work

Courage and Respect are 2 of the 5 XP Values; and Energized Work (aka Sustainable Pace) is one of the Primary Practices. I want to share a work ethic that would seem to be opposite of these values and practices; I will then demonstrate how it is actually just another way to implement XP practices and how this work style has these value built in.

I was recently involved in a task which required me to work very long hours (12-16 hours a day); not only that, I was working on the weekends as well. I was not alone in this endeavor, I had a team of 3 working with me. We had been at it for almost a week now. This goes directly against the popular notion of "Energized Work" practice of XP.

Energized Work

This practice states that developers should not work more than 40 hours a week. And any overtimes should not be followed by more overtime in subsequent weeks. The way to interpret this is that programmers should only work while their brains are working at their 100%.

Respect and Courage

These values depict faith in in your fellow team members and having enough trust level in their abilities. They also depict persistence: the ability to not give up on a problem; the ability to return to the problem the next day and solve it.

The Other Viewpoint

Let’s get back to my work week last week. There is no way that I could be doing any kind of ‘Energized Work’, right? Wrong, says I. Energized Work means that you should be doing your best work when working. This is normally true if you are doing a long term project. However, if you are doing a short term Proof of Concept of sorts, then it is possible to give your 100% even while working insane hours. The reason is that you know that this is only a short term effort.

But this knowledge is not enough for you to keep giving your best. The other thing that keeps you going in such assignments is the challenge involved, the team, and the inherent desire to beat the problem which keeps you from quitting and keeps you going at close to a 100%.

This allows you to put a very high level of work, which fulfills the Energized work requirement. You continue to toil because of the software, and not because of the job. Since you are working in a team you have to learn to respect each other’s work because and lack of respect might jeopardize the whole objective; so you end up trusting your fellow team mates, and they usually end up justifying that trust. And finally, the reason you don’t take a break is because you are so highly persistent, thus displaying Courage.

Wrapping it up

Like anything else there is more to XP than meets the eye. Books can only teach you so much and one should try to go beyond what the words say and try to understand the spirit and motive behind those words. Most of the time guidelines are to cover 99% of the scenarios and if you fall in the 1%, it doesn’t mean that you cannot follow the spirit behind XP. The point I am trying to make is that XP can be adopted (should be adopted) to your style and requirement of work even if it doesn’t conform to the traditional model.

What are your experiences in adapting XP to your style of working? Do you agree that the case described above can be categorized as XP?

XP Values: Respect

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of respect is special in that it is the only Extreme Programming value not present in the first edition of the Extreme Programming Explained. Kent Beck added it to the second edition basing on how the first book has been interpreted in many companies out there. Extreme Programming is no fixed mechanical process that anybody could be forced doing. It is rather a way for continuous improvement of the practices so that step by step the business, the team and the individuals could improve their ways of work. Such a continuous improvement is based on the regular retrospective analysis, the will to improve and the belief in that changes can be performed. It can hardly happen without the high level of trust and respect between the team members, management and the customers. Only a team of respected professionals can feel empowered enough for being highly innovative and creative in their solutions and in the work practices improvements.

Primary XP practices directly supporting the value of respect

  • Whole Team – the whole team team commits to the goals and the whole team is accountable for the results. There can be specialists, but there are no individuals working and responsible only for “their tasks”. Everybody is respected enough to help no matter how simple his problems might look like to the more experienced team members
  • Energized work – it is natural for everybody to make mistakes, also estimates are no promises. It is not a guilt if some estimate poorly correlates to the reality and it is no reason for forcing people “failed” at estimating to work overtime
  • Pair Programming – the XP team accepts the fact that the second pair of eye-balls and the second perspective on the code  are useful whatever the paired person experience is like

Corollary XP practices directly supporting the value of respect

  • Real Customer Involvement – talking to customer is not the privilege of the marketing department, but the mandatory condition for producing the software the customer really needs
  • Team continuity – a team of respected professionals deserves to be valued more, than mere “resources”. It is better to “waste” a bit of “efficiency”, than to dismantle team of professionals working well together only because the next project could be done by the smaller number of people

This page is a part of the Extreme Programming overview

Weekly Agile Reading. Pack 2

This week I noticed only two lately (since last Saturday) published items that are worth recommending to you

Top writing of the week

See also

If you happen to encounter another interesting content published since last Saturday, please, post links in the comments.

XP Values: Courage

Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of courage is about acknowledging the fact that the best way to produce the best possible products is to be honest and transparent on all the possible levels from customer communication to the way you type code despite how uncomfortable the idea of high transparency might look like from the beginning. The courage is needed to admit the team and organization weaknesses. Every organization, team and individual have their strong and week sides and only by admitting their existence it is possible to act on them.

Primary XP practices directly supporting the value of courage

  • Sit together – be courageous to remove the walls so that everybody could see what each one is capable of
  • Energized work – have the courage to state and explain that the 40-hour week and sustainable pace lead both to higher team morale and better software produced faster
  • Pair Programming – let the other guy see and feel how you program
  • Weekly Cycle – don’t be afraid of the frequent evaluation of your work
  • Slack – accept the fact that there might be the need to drop something if some feature is more difficult for you, than it was expected


Corollary XP practices directly supporting the value of courage

  • Real Customer Involvement – communicating with the customer might be not too easy for some developers, but it brings in a lot of information on what the customer really wants
  • Root Cause Analysis – don’t be afraid of looking for the deepest roots of the problems. The devils uncovered might not be the most pleasant things to admit, but once they are realized the organization might eventually try acting on them
  • Daily Deployment – don’t be afraid on demonstrating the real product quality often. Better work on making it work daily
  • Negotiated Scope Contract and Pay-per-use – let the trust and transparency be your friends, when earning money

This page is a part of the Extreme Programming overview