MDD

Well, I wanted Specflow to be magic, but sadly it is at best a good-looking text editor. It constriction to .NET makes the pseudo-code generation easier for the product, but it failed spectacularly with any other Visual Studio integration. Which made it all seem a bit pointless. You could create Features, you can generate pseudo code (basically the unit tests). You can maintain the features and update the code in one smooth action. But that’s not Specflow, that BDD (Behaviour Driven Development). BDD on its own goes nowhere – applied with Scrum management and it can work excellently. But only of greenfield projects, or upgrade project which has implemented this methodology already.

Forgetting Specflow for a moment – actually completely – BDD is good method to keep development on track with requirements/user stories. The granularity covered in analysis and planning stages takes longer, but is negated by the increased speed of development time. The problem with starting development once user stories and scenarios are defined, is issues could arise in the course of implementation, that could have been foreseen with more development involvement at analysis stage. That does not mean that is an error in other approaches – methodologies are not for the dumb, the assumption is you will use the method as a base rather than just blindly follow the outline.

BDD fails for one reason – failure to maintain momentum with user stories/scenarios and development. There is no substitute for project management, which is what I feel these methodologies can imply, or are simply misread. Apparently 75% of Agile projects use Scrum for project management. For development management there are a lot more alternatives within Agile scope, and the best way to decide which one is on your team and projects drivers. Thankfully the previously common assertion “We’re working Agile!” has started to fade. Too often it is used as an excuse for chaos.

It is ironic BBD is also acronym for Body Dysmorphic Disorder – as the reality of BDD is usually very different from the perception. And in order to get a process to work, we sometimes mask the defects to the process. Methodology Dysmorphic Disorder(MDD) – I believe that is my first acronym, maybe it will catch on! Problems when applying methodologies are usually identified within the methodology. But that simply because a methodology cannot cover every situation – we are dealing with human beings here. Rather than find fault in BDD, it was the implementation that went awry, because of human flaws not methodology flaws. Or even Specflow flaws. To improve on process weaknesses, you improve the communication and integration between people.

To Specflow: I am aware I have been guilty of “build them up, then knock up”, but it was good reminder that software doesn’t always provide answers, and in fact, can cause more problems.

How Agile becomes fire-fighting

What is the obsession with saddling people with combined roles in Agile – and often they do not even know they have two – it’s assumed. The project manager was split into two roles – Scrummaster and Product Owner. I do not believe there was anything wrong with the role of project manager, but the Agile division made sense utilizing development management skills of planning and maintaining momentum, with the (assumed) business analysis and planning skills of the Product Owner. It makes sense on paper, but with the splitting of roles, comes more risk as you have to have the right two people. Very often the Scrummaster or the Product Owner falls into project manager role, due to weakness in one or the other.

In industries still early to Agile, they retain the usual Waterfall role structure, though development managers have become a rare sight. This actually doesn’t have to mean a disaster – the Agile roles are still fulfilled to some degree, although the Scrummaster/Product Owners are recombined into a project manager. In those circumstances the Project Manager will have a stressful time – and highlights that there is a good reason for the PM role split. To work in a Agile fashion is more demanding on planning, and it’s a bad situation if the project manager is spending 95% of his day on MSProject (or something less hideous).

Even worse scenario is when the Scrummaster and Product Owner roles are “missing”. Either through inexperience within the team, or people rejecting their roles by simply not performing them. Sounds strange? Look in any corporation and you will find this situation. The onus is that situation is that the developer(s) understand what is required to deliver an Agile project. But the stress this time is firmly in development camp – just the place where you not want a stress-overload. You will end up with a project that bounces around (and largely on the spot).

Comining roles can sometimes be sensible business move, but in Agile the roles are seperate for a reason. Ingore them, and dont’t even think “we’re agile!”. At best you will end up with a faster Waterfall struggle. If you are struggling to fill roles effectively, then maybe the methodology isn’t for you … not without changing your approach.

SCRUM is not an island

SCRUMIn 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, computer, photocopier, and printer industries.[1] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth”.

The first time I encountered SCRUM in 2001. The development manager was utilising pair-programming and daily standups. The project failed, largely through chronic mistakes made with market analysis. But it did introduce me to a new concept of telling a group of people what I had been doing, and what I was going to do. Just a simple idea, as all the best ones are.

SCRUM has been inexorably tied up with Agile methodology, but it predates its formal manifesto (2001). It addresses a key problem in projects, which is momentum. All human beings need a reason to do something with full committment. Deadlines are there not only for clients, but driving a project forward to a known point in time. So it logically follows that the deadlines of releases also will create momentum towards the final goal. The concept of daily meetings is again, not new. These short daily standups keep a project on track, but all involved knowing whatever anyone else is doing, and allows a forum where blockers and other concerns can be raised.

Planning on Agile projects are challenging, given the short increments, and the necessary connstant reviews and changes that are inevitable. SCRUM is largely focussed on this area of project (Agile on the software development process). Because of Agile’s driving focus, which is rapid iterative software development, it needs as strong process that is enforced. SCRUM addresses the project management side of Agile, devolving the role of Project Manager in Product Owner (or Product Manager) and Scrummaster. What SCRUM includes in its roles are:-

  • ScrumMaster – who maintains the processes (typically in lieu of a project manager)
  • Product Owner, who represents the stakeholders and the business
  • The “Team”, a cross-functional group who do the actual analysis, design, implementation, testing, etc.

Notice the last role? It isn’t a role at all, it the people who make SDLC happen. This is where Agile steps in. If the Scrummaster is weak, then you might as well drop SCRUM to start with. Too often with SCRUM, the focus is on it as a development solution rather than a project management one. Agile and SCRUM require radical rethinking of planning, more change than most traditional project managers can handle (hence evolution of Waterscrum and Scrummerfall).

Its an imperfect world, and Agile projects generally do partly succeed, but a lot depends on the team you have. In fact if you have the right team together, then methodology is virutally inconsequential. A good developer knows the importance of the testers, and also the stakeholder. This should be a mutual respect, and makes for a very cohesive team.

Maybe just my opinion but there is something always omitted from Agile planning which is pace of momentum. To drive your project team into the ground, simply try and apply same pace all the time. Human beings work better in a slingshot fashion – slow build-up leading to more powerful movement. This is the way to operate Sprints, not by Sprint just sliding into each other release after release. I thought it was just me and my quirks, but people respond better and more consistently when there is time to reflect, learn from, and feel proud of what has just passed.

When drowning in buzzwords …

… its a good idea to go back to fundamentals

Kano analysis was created by Professor Noriaki Kano in the 1980s and is used to optimise a product by categorising its features by perceived customer value. In a simplified form, a product’s features can be split into three types:

Essentials – those product features are essential for the customer to even consider buying it.

Linears – those product features that are linearly valuable, ie those where doubling an element of the feature is perceived as being twice as desirable.

Delighters – those product features that delight a customer – usually only a small number being necessary.

Agile Business Change Blog

Free online load testing

Load ImpactA useful quick load test tool (for free you can get steady rampup of 50 users, which is enough to do some initial analysis).

It won’t work through proxies, but then that’s your fault 🙂 If you want to use the proliferation of online tools, it is better to restrict access to your alpha/beta site by IP access. Too many companies shoot themselves in the foot with paranoid proxies which can make developer and tester life hell!

With this tool you can load test a site URL 4 times a day, and registration enable you to save test configurations and results to your account. Worth the short registration.