Scrum Case Study 1

In the most perfect of methodology application, there is always room for improvement. To assume otherwise is misguided over-confidence. Take Scrum, the most used (and abused) of the modern methodologies. The principle, as always is simple – better project management and more control over requirements. It requires more future planning, consitent review pattern, and following through to the development process. It is no good having good project management, if the development teams are not following through with code.

The project was a middleware service providing Always-On email system. Though common now, this was in 2005 so the concept of a true mobile LAN email service was relatively new. The first action was devising a test strategy, which defines the high-level testing scope and testing cycles. Though a middleware service, it still has to be verified for the input and output, i.e. email sent, delivery and verification of content. The company had adopted a system of using real phones and emulators to test email content and user experience. The focus of our testing was on the core application and database, which would pontentially servic a high level of traffic.

The project was working with an efficient Scrum management and Continuous integration process. They were very competent developers and the architectural team also very skilled. But what comes with these talents is overlooking chances for improvements. The end-user experience was paramount in gauging success of the middleware. End to end testing was the most efficient and useful method of testing. I am not there to pointlessly increase scope of testing for financial gain. Consultancy should have morals. What I needed to add to ensure a controlled QA gate for releases, was a test environment, and test framework to provide the external and better overview that QA can provide. The problem I identified to begin with is that they were working in solely Incremental fashion, when Iterative AND Incremental is a better approach to deliver to requirement. People may now at the mention of “milestones”, but when else is a client going to get what they want?

For the essential load testing I chose STAF, an open source load testing framework, driven by xml-based user profiles. This was perfect, as user profiling was very appropriate for email users. The advantage of using open source tools is they act as a kcik-start to what you are actually looking for. Rather than letting the tool dictate what you test and how your test. It some work to get it up to the standard you want, but ultimately more useful and can be included in development cycle. Developers will find them useful also, and more likely to gravitate to open source, over bespoke commercial products.

Using Kanban for Scrum improvement

…. sprinters believe that — someday — somebody will run the 100 meters and the clock will read 0.00

Before I start it is important to note, with Lean/Kanban, we are entering an area trod by Agile/Scrum, and people’s need to have abstract generic solutions. In order to properly utilise these processes, requires thought and planning.   My first experiences of Kanban was on a re-factoring projects, and it seemed as if Kanban approach was ideally suited to a project that was likely to uncover surprises. But scratching beneath the surface I realised it was a far more efficient project management style, that mirrored general Lean software development principles.

Continue reading

Project karma with Kanban

When things go wrong, especially at work, change is preferred over learning from mistakes. By not reviewing what went wrong, you run risk of simply making a bigger hash of it.  A good analogy is when you attempt the nightmare that is flat-pack furniture.   Instructions for these finger-busting items are rarely wholly descriptive or helpful.  So is the problem with the product or the instruction?  Well both usually.  We can’t review/improve the instructions – or can we?By spending more time on the instructions, identifying the easier steps and trying to decipher parts with less clarity, we can improve the process of assembly.   So rather than accept the poorly written manual, and grumble as we assemble using our own logic, a more positive step is to review and improve what is there.  This does several things – highlight glaring omissions in instructions, clarify more vaguer areas, and prepare the assembler better for the task in hand.
Continue reading