Agility and more: better & faster business solutions with software - part-2

In my previous blog post, I talked about why software development needs processes, and the need for agile in the processes. Here, I continue with the discussions, focusing on how the basic principles of agile itself has a lot to say, that can help us build better software.

Practicing agile - adapting is more important

As mentioned before, the popular practiced tools for agile process include Scrum, Kanban and XP. But often, the process models/tools are applied as a religion, being strict on what the text prescribes. This has resulted in some rumblings that has questioned the effectiveness of agile processes to deliver quality and creative solutions to business. The InfoQ book on Scrum and Kanban has highlighted the need for the process models to be adapted to their needs.


So what needs to be practiced is taking a lean model, and adapting it to your needs, probably by adding "prescriptions" from the stouter process models, and even removing "prescriptions" that hinder your progress, but with absolute knowledge of what is being removed. This is what Henrik has put in his InfoQ book - "Do not limit yourself to one tool!".


I have my own experience, where we started out with pure Scrum. Scrum iterations help evolve not only the software but our (scrum) process itself with continuous retrospectives. As we practiced it, over the time we hit against the walls of the Scrum, such that we had to eventually remove few prescriptions of the Scrum, effectively making it leaner and the process as "Scrum Inspired". For example, we would feel OK to extend our sprint for 2-3 days and still declare it as a successful sprint! We would find it OK to even entertain new items during the sprint, if it was critical to the client. Sometimes, 1 or 2 team member may work on items from another product, that is planned in advance for the sprint, because we had small teams, and the same team members would work on multiple products/projects. In spite of this, we always knew where the limits were, and we were effective with whatever we did. We were strict on whatever process we followed. If we changed the Scrum rule, we did that knowingly, and probably would be the outcome of the retrospectives we had at the end of sprints. By adapting the process, not only was our output improved (that would make customers happy), the management as well as the team members were happy at what we do, and how we do it and the overall team productivity.

We all were extremely happy on the retrospective day, since it was the day we could blast out our rants, impediments and criticisms openly. We virtually had fights over the retrospectives. But finally, it all would help us improve what we do.

Mix-n-match and adapting is important. For instance, Scrum does not say anything about releases, but XP does, hence combining them together is more compelling. The "Do it" nature of scrum and the "pair programming" and "move people around" principle of XP and a well communicated team also helps in getting a new joiner to be inducted fast into the team as well!. Most of us have done pieces of XP and agile knowingly or unknowingly, if for example we have written unit tests, did iterations of development and the like. But the real benefit for going agile comes from developing and following process models with prescriptions from the agile processes available. Process models such as Kanban actually give us metrics to measure our process against, and take the best of what works for us from all the process models - agile or not. We can choose to start  out with Kanban, with probably the regular iteration, daily stand-up meetings, and retrospectives from the Scrum, add to that the software engineering specific practices from XP, such as CI, unit testing and pair programming.

Again, what is more important is to adapt the process models to your needs. For example, even as I mentioned above for practicing prescriptions from Scrum and XP, I am still wondering how a stand-up meeting would happen for a distributed team? Distributed Scrum? Probably, we can have scrum of scrum, but again, this is something I have no experience. So, when the need comes for it, I will give it a try, practiced, adapted and practiced and improved so on.

Responding to change over following a plan

This is one of the four core values of the Agile manifesto. Adapting your process is a definite way to achieve this objective. Agility promotes responding to change inherently because of its iterative nature, that can enable the team to incorporate changes to a software more rapidly that traditional classic waterfall model. Process framework such as Kanban further fosters this changes to be percolated more rapidly into the development.

Try experimenting. Experiment with new and innovative ideas for improving processes. Invite all sort of crazy ideas from your team as well. I am sure, you will not go worse even if your experiments failed. You will learn so much. Next time you always know what not to do :).

Focus on individuals and interactions over processes and tools

This is again one of the four core values of the Agile Manifesto. This is what we have covered already. Let me explain. By focusing more on adapting the process to our needs instead of following the process as a religion, we are focusing more on the people and interactions for sure. The stand-up and the retrospectives for example are effective to give importance to the people who are involved, removing their impediments, and giving importance to their interactions. Once we practice scrum and XP, there is a value that the team learns. It is more important to follow these values, than to follow these practices by book.

Communications and Interactions

As we talk of individuals and interactions, I should emphasize on the need for effective communication and interaction within the team and with the customer (or his representative). Well communicated teams is one of the focus of scrum and XP (and most of the agile practices). The team stake holder should ensure proper communication channels. Small and well knit teams help a lot on this. If a team member has a problem, he knows already to whom this should be addressed, and the turnaround time to address this should be maximum of two meetings - i.e, the impediment should be addressed before the second team meeting after the impediment had been raised.


To enhance our communication channel, we used enterprise blogging at three levels:

1. Organizational blog: We used this blog to express new ideas and rants across teams.
2. Team blog: we used this blog within the team for various purpose
1. Daily status update - every team member used to put the daily status update for days work under the following headings:
• Tasks completed
• Tasks pending
• Impediments
• Things I found new today
• Comments
This daily status update, served more than one way to increase our effectiveness. Members would take a look at the updates for the day from other members before the scrum, and come prepared for it. It was also helpful, if a member was was absent on the day, or could not make to attend the scrum for some reason.
2. Project specific posts - To discuss and document a project specific problems, and ideas. Many times although, we would promote some of the posts to the organizational blog too.

One-to-one interactions are really good at fostering better communication and interactions. It will be extremely good to have your team work at the same location, if possible within same cubicle. ThoughtWorks practices this with "Dining Table" culture for the team that fosters greater collaboration and communication (and flow of ideas). For distributed teams, this may not be feasible, where better interaction can be provided by having the team members available to each other on IMs. Use of wiki based whiteboards as discussed above can be a good way to go for distributed teams. Well, there can be a lot of talk for this. So I reserve the 'distributed teams' topic to a separate discussion.

Human factor

While focusing on individual developer productivity is important, it is also important to see how the team as a whole can mesh well and be productive. A very important thing is to have well-knit and well communicated team. Focus that they can work well with each other considering the human emotions and social factors.

Frequently changing the context is not a good idea. Everybody may not be equally good at changing contexts. It would be nice to group together similar tasks. Human minds takes time to get adjusted to the new environment and get productive. Again, this is a topic that may itself need a separate discussion.

Tools do not replace process and individual interactions

When we started out with Scrum, we used whiteboard for everything - from daily tracking our burndowns at daily scrums to the retrospectives. But later to keep track of what we do, we moved parts of these into our enterprise wiki. Later we also tried with JIRA's GreenHopper plugin to manage most of the scrum, except the retrospectives. We where still open to change or adapt to tools as would our process be adapted. In short, we used the tools to aid us what do.

Using tools does not mean that we are doing what the tool is meant for.  What we do for scrum is more important than the tool used to manage scrum. Using the Agile PLM does not mean that we have gone agile. Tools should be at our disposal to aid us what we do more effectively.

Focus on the developer skills

A craftsman is the center-point of every creation - not just software. From the craftsman of a building to that of a supersonic jet aircraft - the skill of the craftsman involved is very important and crucial to it. Software craftsman is no exception.

The developer should realize the importance of developing skills even beyond his current needs. Developers should proactively try to learn, innovate and come with new ideas. Always try to learn something new at work, and from around your (professional) community. Work proactively to improve the environment you work in. Work towards a more productive process, for getting better output for your company and yourself. No one can teach you or or force you to learn. It has to come from within. Try reading books, blogs and articles, try to keep up with what is happening around. Find how a new technology could help you create better software. Find how a new technique or trick could help you do more with less effort. Attend conferences, and user groups, speak at them, share your learning - good and bad, blog about them. Peter Goodliffe and Dan North have some (pdf) interesting advice (pdf) on this topic that they presented on the recent QCon London 2010 conference.

As software shops that nurture these software craftsmen, it is important to promote them at these things, and provide a conductive atmosphere for the developers to nurture their skills. I will discuss these things in later in this post (series) under the title "Some Agility and beyond".

Focus on working software over comprehensive documentation

This is again one of the principles of Agile manifesto. But this often creates confusion and debates. Since, many times good documentation is called for a good software.  Because, at later stages, a software without documentation, may be hard to understand, and maintain. However, this principle, does not mean to avoid documentation. A good discussion on agile documentation is provided here. After all,  documentation is all about communication, so as mentioned before - documentation is just a medium of communication, focus instead on the overall communication.This topic alone requires a lot of discussion, but let me discuss few very important topics in this.

Code is your document

Documenting your code - code is your document. Code commenting, with importance in probably what is the intent of the code rather that what the code is doing,.. any good developer will understand what the lines of code do, if they know the intent of the code. At times, for an intent you may have to write a lot of classes and methods, there put the intent at the index/root of where it all begins, and probably give reference to it. See the JDK, or the Spring API documentation,.. its so beautifully documented.

A test-case is worth a thousand words

Developing test case is also a good documentation, to showcase the functionality. The test-cases can be automated unit test cases, that very much is a very good documentation - technically as well as functionally. Tests should run in all possible ways - regular builds, test builds, CI builds, and even in IDEs. I will cover more on this in my next post in this series.

External Documents

You will have to maintain external documents too. For example, a document that discuses your architecture and its intentions. Focus on developing the software first, and writing documentation for the working software instead of writing for speculative design. Managing external documents, should be among the task list during your iterations. And very important of all, keep in a format that is easy to edit and maintain. You may have a document management software to maintain them or it may be as simple as managing all of them in your enterprise wiki.

More to come ...

In the next blog post in this series, I will try to explain practices that stretch beyond agile prescriptions, that can help build better software. While some of the practices are within the agile prescriptions, few others have also been recommended by Agile experts such as Martin Fowler, while few other are practices that have been proved to work, to produce some admirable software, while having a happy team.

Update...

• Part 1 of this blog series.
• Part 3 of this blog series.