Finding the Right Process

Agile teams are often faced with a dilemma: how much process is the right amount of process for us? There’s no right answer, of course, and the closest thing to a right answer can change as often as you change your socks, which, for the sake of your teammates, I hope is pretty often.

The amount of process your team needs to succeed is influenced by a variety of factors, such as team size, team skill, honesty and trust, management style, your product domain, your team’s understanding of the product domain, access to your customers, and much more. There are too many factors and variables to even consider coming up with a formula, so experiment — try doing some new things, try not doing some old things, and see what happens.

Processes that add no value detract from those that do.
Every part of your development process should be done for a reason. If no one can explain why you’re doing something, stop doing it. Of course, if you stop and it becomes evident that you shouldn’t have stopped, start again. Pruning defunct or costly activities (including “busy-work”) helps to emphasize the value of activities that are important to your team’s success, and your team will be more likely to embrace and excel at those activities.

For example, if your team practices Pair Programming but can’t explain why, try an iteration without pairing. If the defect rate triples (barring any other obvious factors), it’s probably a good idea to start pairing again to get quality back on track.

However, if your team members submit a weekly status report in addition to daily stand-up meetings, you may find that the weekly status report adds no value other than helping a distrusting middle-manager sleep at night.

Start small and tweak the processes that you already follow.
You don’t have to eliminate an activity to understand it or increase its value. Your team probably can’t pair program for 8 hours every day, but can they do it 2 hours a day, 2 days a week? If that works, can we try 4 hours a day, 3 days a week? We write a lot of unit tests, but can we try writing tests first? Can we increase our velocity and quality by writing acceptance tests?

Retrospectives are a good time to bring this up. What worked, what didn’t? How can we improve?

There are some things that most Agile teams should do.
Automated testing. Continuous integration. Collective ownership. Small, frequent releases. Refactoring. Retrospectives. The vast majority of software development teams benefit immensely from these increasingly common practices. It’s hard to imagine a team being successful over a significant period of time without them these days.

That’s not to say that you have no flexibility — it might not be worthwhile for the entire team to be fluent in your most complicated business logic, but buses (often labeled “Exciting New Job”) have been known to hit experienced programmers from time to time.

Experiment, experiment, experiment.
You don’t know if something will work for your team unless you try it, and you often don’t know if your team will fall apart without a process that is considered critical. Don’t be afraid to try new things.

Why Scrum Product Owner is a Hard Job

Scrum teams as well as the teams applying another agile software development processes build software iteratively. Sprint by sprint they release increments of software that is DONE. Planning in Scrum is also done iteratively. Low priority coarse grained backlog items are refined when they come close to the top of the backlog. The purpose of such an iterative planning and releasing is not to maintain the original project coarse, but to continuously adapt to the changing business requirements and to the increased understanding of the technology and the subject area.

Frequent Decision Making

Therefore Product Owner has to continuously care about the project direction, refine its goals, make sure that the product backlog is reasonably detailed, still conforms to the product vision and that the vision itself is still valid. When possible Product Owner almost like XP’s customer on site during the sprint continuously interacts with the team not only clarifying the product backlog items (ideally – user stories), but often also deciding which solution exactly is good enough for him.

This is quite different from what a traditional project manager might have used to. In Scrum the traditional planning phase is dispersed over the course of the project. It requires much heavier involvement during the development and calls for making business decisions frequently. Sprint by print Product Owner has to be actively involved in evaluating the team deliveries, accepting the challenges and in refining the project direction.

Customer Involvement is Vital for the Project Success

Not all the customers are ready for such a workload. However, the direct and frequent involvement of a customer or his proxy (product owner) is what it takes to build a software that is actually useful for the customer.

Do you enjoy Self-Organizing team?

There days many organizations practicing Agile processes are expecting team members to be multi-talented and be able to work in variety of situations. More frequently we hear the terms like “Self-Organizing” or “Self-Managing” teams in the Scrum world.

In the software development we have learned that the software is becoming more and more complex as the variables technology and requirements change (thus the upfront planning has become famous). In the traditional project management, the project manager used to take the responsibility of the Risks, Complexity, Deadlines, Release Plan, Testing, Documentation and etc… On the contrary the self-organized team is set of individuals with different skills and mostly complementing each other. This team is organized and re-organized depending on the project pressure, schedules and deadlines. This team wears different hats depending on the situation. This team works on a simple rule that “Tell me what to do; But not How to do” and sometimes even the baby steps.

The team knows how much work can be done in a specific sprint. Nothing is as de-motivating as someone else commiting on your behalf. Its very encouraging to fulfill the responsibilities that you have committed to. Teams can be cross-functional and to such an extent that a developer might do testing when there is a crunch on the testing resources. He might even help a sales engineer to train the customer and make a POC. Every team member works towards a useful or tangible task for a day. This reflects in everyday scrum meeting by the three self-organized questions

  • What did i accomplish from yesterday morning
  • What do i want to achieve till tomorrow
  • Are there any stumbling blocks for my work

Self-organizing teams are definitely different from the conventional Manager Managed teams; but its a definitely wonderful tool for greater productivity and a fresh breath of air for many.

I am sure many of us would have definitely had great experiences in working with Self-organizing teams. Do you enjoy working in a self-organizing team ?

10 Signs That You’re Not Agile

Since most readers of this blog are likely to be practicing or budding Agilists, replace “you” with “your coworkers” or “your manager” as appropriate.

1. You haven’t seen or spoken to a coworker about work for at least a day.

Even remote team members should be in contact on a daily basis for Scrum/stand-up meetings and throughout the day over the phone/Skype/IM/email. On-site, co-located teams really have no excuse to work in isolation.

2. You email a status report to your manager, attend weekly 1-2 hour status meetings, and you and your coworkers still have no idea what each other is doing.

Often a consequence of #1. Scrum is a good way to report status efficiently, facilitate face-to-face communication, and make commitments to each other rather than management.

3. You can’t remember when the last build passed without manual intervention.

This happens if you’re not doing continuous integration on a clean (not a developer’s) machine at a minimum of once a day, but preferably whenever someone checks code in to source control. You are using source control, right?

4. You write a 30-page specification (which the customer signs off on) and still don’t build the right thing.

Good old Waterfall, Big Design Up Front, and Cover Your A**. Instead, favor open, continuous communication with the customer or her representative, including continuous release/demonstration and feedback. This allows you to adapt to changing, or simply miscommunicated, requirements.

5. You think unit testing is QA’s job.

It’s really amazing how many developers, including (especially?) senior-level developers, haven’t grokked the benefits of unit testing. Somehow any practice with the word “testing” in its name is up to QA to figure out, if you’re lucky enough to have a good QA department and process. Unit testing is a “white-box” (or glass-box if you prefer) test — leverage your knowledge of the implementation to fully exercise the code under test. QA typically operates at the black-box level, without understanding the fine-grained implementation details, like a user.

6. You think quality is QA’s responsibility.

Sounds like #5, but a bit different. Everyone is responsible for quality, especially developers. The sooner a bug is found, the cheaper it is to fix.

7. Your project schedule contains 18 months worth of fine-grained tasks, but no one knows who estimated the work. (Or the person who made the estimates isn’t doing the work.)

No one knows for sure how long it will take to design, implement, and integrate a software component. But the person who is designing, implementing, and integrating it should be able to make the best guess and will have more incentive to produce accurate estimates.

8. Your architect doesn’t write code very often, and that’s probably a good thing. Have you seen his code?!

A lot of architects are great. I’ve worked with a few that were hands-on and knew their stuff. They knew the environment, languages, libraries, and legacy code as well or better than most of the developers. But architects who don’t get their hands dirty can be dangerous, especially if they opt not to consult with their lead developers on important design considerations.

9. Every time you make a relatively small change, it takes days or even weeks to integrate and regression test.

Without continuous integration, a good test suite, and solid design, touching even the seemingly most innocuous line of code is a risk to distant, often unknown, relatives than depend on the behavior of that code.

10. You’re not allowed to refactor. We’re shipping in 3 months and refactoring is too risky!

Definitely related to #9, but that word “refactor” is especially scary to some, especially if you don’t have a good test suite for a safety net. It’s also scary if your team doesn’t understand what refactoring is, and uses it to describe massive redesign — management is once-bitten-twice-shy when it comes to that sort of thing.

Agile , Tacit and Web 2.0

I have consolidated some good definitions and principles on the topics Agile Development / Tacit Knowledge / Web 2.0

What Wikipedia says about Tacit Knowledge :

” …Tacit knowledge is knowledge that people carry in their minds of people and is, therefore, difficult to access. Often, people are not aware of the knowledge they possess or how it can be valuable to others. Tacit knowledge is considered more valuable because it provides context for people, places, ideas, and experiences. Effective transfer of tacit knowledge generally requires extensive personal contact and trust.

Tacit knowledge is not easily shared. One of Polanyi’s famous aphorisms is: “We know more than we can tell.” … ”

Agile Manifesto Says :
“..We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more .. ”

Web 2.0 principles says:

“…web 2.0 is sometimes called the e-Democracy which has the ‘architechture of participation’ as the base…”

Does the above words have any relationships within them ?

Please give your commments and thoughts on it …

Risk analysis in agile methods

Risk analysis in traditional software development projects is often performed for real only before getting the financing and actually starting work. After the project ends there are often the “lessons learned” sessions, which in case of a failure are called postmortems. During these pre-project and post-project risk analysis activities an attempt is being made to reduce the risks and maximize the probability of success. The recent addition to this collection of methods is the idea of a premortem that is a risks review that happens before the project start as if the projects has failed already. While all the pre- and post-project risk analysis techniques are indeed useful and can help organization to improve own practices, they only look at the potential problems at only two moments of time. Therefore there is always a danger of missing the important factors that either did not exist at the point of analysis or team members did not have enough information about those.

Agile software development methods recognize the difficulties of predicting the future challenges and complexities of both nowadays market and technologies used. Agile methods advocate reevaluating the project risks frequently, after the fixed periods of time – before every iteration start. Such a steady rhythm brings an explicit attention to the issue. What is even more important, as much as possible, the analysis results are not just the general recommendations to follow. All the agile methods explicitly recommend attacking the uncertainties and risks by constantly prioritizing the most risky elements high and exploring the most uncertain areas first. In practice it means exploring and prototyping the most ideas right after they have been identified as risky. For example, whenever scalability of the current architecture is identified as a potentially big issue, the scalability related tests, experiments and improvements are recommended to be performed before adding any more features.

What do you think? Does the agile-like reprioritization-oriented periodic risk analysis make sense and bring the tangible benefits to the company?

Why are Standup Meetings effective?

Standup Meetings” is one of the core practices in the Agile Software Development. Instead of meeting the team once in a week in a meeting room, daily 10 minute Standup Meetings are quite popular. Few teams – which do not have a clear idea of Scrum – consider these meetings as personally intrusive and intimidating. But what one can gain via Standup meetings are many fold then conventional meetings.

Well known reasons for effective standup meetings include…

  • As you standup for meeting, you tend to finish the meeting fast (no kidding)
  • This encourages courage among team members as they talk about the progress daily
  • Any issues would be raised and addressed on daily basis
  • As the entire project team is present, transparency is the key in communication
  • Chances of false promises by a member are less, as they are in front of the entire team

Once the whole team is punctual for the daily standup meetings and addresses the right issues, eventually this acts as a risk mitigation and preventive plan for the entire team. Its based on the simple principle that “The sooner we address the risks and problems, less are the project failure risks”.

XP Values: Honesty

“Honesty is the best policy — when there is money in it.”
– Mark Twain

XP requires constant communication between team members. More specifically, XP and Agile teams depend on honest communication between stakeholders, including developers, testers, managers, and customers.

We expect manufacturers and vendors to be honest to us about the products and services they offer and market to us. Our customers expect the same. Honesty is especially crucial during iterative development where a minor course correction early in the schedule can save significant time down the road.

  • If our customers aren’t honest about what they need vs. what they want, we won’t build something of value.
  • If developers don’t provide honest estimates (to the best of their ability), management can’t accurately plan the release, budget, or allocate resources.
  • If developers aren’t honest about what they’ve built, testers will waste time testing features that are incomplete or frequently changing.
  • If testers aren’t honest about quality, the customers will not have confidence in the product.

Why we lie.

We’re tempted to lie (or just bend the truth) for a variety of reasons. We want to make ourselves look better/smarter/faster. We don’t want to let the team down. We want to get something for free.

We don’t think, or we hope, that no one will notice. Sometimes no one will. Sometimes they will, but won’t say anything (and surely won’t trust you in the future). Sometimes they’ll say something, and you’ll look worse than if you had simply been honest.

Encourage honesty by being honest.

In my opinion, the best way to encourage honesty is to be honest. Others will notice, even subconsciously. A culture of honesty and openness makes it feel dirty to tell even a small untruth.

Even if you have bad news to report (“I might not get my work done because my cat is sick”, or “Oh, no, that’s not what I thought you were going to build”), it’s better to let the appropriate stakeholders know, and let them know as early as possible so that any necessary adjustments can be made. Everyone makes mistakes, everyone slips, and everyone misinterprets a request now and then — it’s how we handle these situations that defines our character and makes us successful.

DISCLAIMER: None of this applies if your significant other asks, “Do these pants make me look fat?”

Weekly Agile Reading. Pack 9

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

  • Function to Function Pointer Refactoring – Bas Vodde, one of the Nokia agile gurus presents simple yet effective tip for refactoring the legacy C code for testability
  • Morning Cuppa – Dave Nicolette explains how agile software development is similar to drinking a good coffee. Not exactly a humorous post
  • Technical Debt Decision Making – Steve McConnell, one of the most known figures in the whole SW industry explains what exactly differs quick and dirty way from proper and slow way. The main point is that there is actually a quite measurable third path – quite quick, but not that dirty way
  • The NokiaTest: What Does It Mean Really? (1) – Joe Little from “Agile & Business” starts a series of posts that discuss the Nokia Test for Scrum. The first post covers the importance of the timeboxed iterations of less than six weeks length

See also

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