Development Process With a Naked Eye

Creating IT products is always connected with different management, recruiting and development aspects. Someone is paying attention to this process, someone is not. There are many sources that contain information about software development and it's workflow. The most popular thing that you will find about it is Agile.

Agile is a fad that grew up in circumstances where clients don't know what they want. Basically that's it.

No doubt that Agile practice and it's Manifesto promotes solid ideas that are really useful in development process and business relationships. By using Agile you will change a long-term, stressful development to short iterations, terrible loneliness and documents to cozy conversation about your adorable project and things that should be done, and of course crudely managed workflow to a quality focus that includes continuous integration, automated unit testing, pair programming, test-driven development, design patterns, domain-driven design, code refactoring and other techniques.

Sounds awesome, doesn't it?

Let's dive a little deeper

Based on the Agile Manifesto, different methodologies have been generated to advocate their own vision of agile values implementation, they are also called frameworks.

If you keep reading this article, probably you've heard about Scrum the most popular agile practice that embraced IT world with it's new standards, solemn trainings and bombastic certificates of 'Scrum Master'.

As other agile methodologies, 'scrum' used to be based on Agile ideas and Manifesto providing best experience in management, making everything and everyone as productive as possible by:

One of principles of the Agile Manifesto is 'Face-to-face conversation is the best form of communication (co-location)'. To cover it, 'scrum' represents a set of meetings that will solve all your problems. Here are several of them:

Sprint Planning (Planning Poker)

Basically, during this meeting the team is supposed to select tasks from backlog (all project tasks), and decompose them for the following time-box (sprint)... Together On one meeting.

This activity is supposed to solve one of the most popular problems within a project miscommunication and misinformation. Developers should vote their estimates for every feature that is put up for discussion. According to the estimate, provided by each developer, the consensus should be reached before proceeding to the next feature.

So for example, the project manager says 'Integrating OAuth Authorization' and a developer might put up number '20', because this is a maximum allowable value.

For more details, please click here

This activity can be also performed with customers, which covers next Agile Manifesto principle: 'Close, daily cooperation between business people and developers' to make the process and customer expectations crystal-clear. This activity should provide solid result by cooperation and opened discussions, sounds incredible!

But if you think about it

Let's start from Agile principle mentioned above 'Face-to-face conversation is the best form of communication (co-location)' total bullshit.

In fact, Github, Basecamp, and many other famous projects were built without face-to-face communication. I'm not saying these people have never met each other, but most of the work was done remotely. Real world examples show that face-to-face communication plays a minimal role in project success. Scrum offers meetings instead of documentation, as per principle mentioned above. But what if I tell you, that this principle has been made by lazy people for lazy people? Endless discussions about features will never substitu well-written project documentation. If the project has it you don't need this kind of meetings.

Cleveroad approach pays maximum attention to composing professional and detailed documentation. Using of outsourcing practices gave us solid conviction that a good project should start from a proper description.

Every decompiled task should be referred to corresponded documentation field, every structure description should contain schemas and illustrated material, every assumptions should be underpinned with research.

Of course, our workflow also contains meetings, but they are held only when the team needs them. Every project team has specific 'voting' rules. The main idea of this voting is to understand that the team truly requires a meeting. So if any member/manager has a topic to discuss, it should be raised up in the project communication tool in a specific format. Then the team is engaged into online discussion if it is worth or not to call up a meeting; if so the convenient time is arranged. When all the details are settled the team takes as much time as it needs to close up all the raised questions.

Our main point is not to intervene the development process with imaginary rules that have no clear utility.

The fact that your team consists of developers on different positions and ranks in truth undermines the whole idea of this super-productive activity which is called 'Planning Poker'. Personally I've never seen Planning Poker performed in a way it's supposed to. Every time when an engineer has put up a particular number, another 'game' begins, I would call it 'Developer of a higher rank tells everybody, what number is going to be'. That means that every time you will see this scene, where the developer provides higher estimate, or even lower (which is the worst case) then estimate that provided by developer with a higher rank, the last one always will have a question with a sour face like 'What?..Really?!' After some useless discussions developers with a lower rank will just accept the opinion of the developer with a higher rank.

Collective scope planning can be presented in more valuable shape then it's proposed by Scrum and it's Planning Poker.

At Cleveroad the collective estimate process proceeds through 3 steps: estimate by the developer with highest rank, comments on estimate from the developer who will actually do it and comments on estimate from the project manager that should contain risk analysis results. When three parties come to an agreement on each feature, estimate can be considered as completed.

So what is the difference?

The main difference is that our teams are not 'playing' on estimate meetings, and not showing estimate simultaneously. The main idea is to rely on expertise of the most experienced developer. Basing on it, developers and managers who are members of that project, should insert their comments to cover all areas and complete the project estimate. This approach saves a lot of time for the team and helps to provide the most accurate estimate for our customers.

It's a daily meeting where everyone should stand up discussing yesterday results and plans for today and barriers if any. Also, these meetings should pass according to specific rules:

1. All members of the development team come prepared.
   2. The daily scrum:
   • Starts precisely on time even if some development team members are missing
   • Should happen at the same time and place every day
   • Is limited (timeboxed) to fifteen minutes 

It aims to help risk management and keep your team informed during the project.

But if you think about it

Let's say you have a project with overall timebox for 1500 hours. The project keeps receiving new features and changing the old ones. How can the task for this behemoth be discussed in 15 minutes? According to Daily Scrum guidelines, Project Manager (or scrum master) should stop engineers in a middle of solving technical issues and say 'Shut up! 15 minutes has passed!'.

In fact, this rule has been created to replace old-fashioned long, stultifying, mandatory meetings, where a few people talk, and everybody else loses their whole day to no benefit. But if reasonable people try to implement daily scrums without limits that interfere overall process, they probably will change old tradition of overly long, onerous, dull meetings to new tradition of overly long, onerous, dull meetings.

As I have already said, Cleveroad sticks with minimalistic procedures that are required for development process. If they do not save time or do not help us we will not use them. For example, Daily Scrum is not required activity for our teams. If the team does not have topics to discuss, then no meeting is needed, in other case, members will just lose work grip for useless 'best practice' activity. Our teams always apply 'voting' to see who needs a meeting and why.

There are also 2 more meetings that Scrum proposes us:

Sprint Retrospective

In general it's a good practice that aims to discuss drawbacks, problems that the team has within the iteration.

Grooming

Has been made by those who wanted to add even more holes to scrum.

Another core idea of Agile is "working software is the primary measure of progress".

In general, scrum underpins this idea with iterations called 'sprints'. By the end of every sprint, the customer should receive the working increment.

Sprint planning is based on team discussions, as mentioned above, and 'velocity' index to measure how much team can do within one sprint. This approach should help the team to receive a frequent feedback from the customer to make changes after every iteration in order to provide expected result to the customer.

But if you think about it

So what characteristic is the main one for 'scrum'? Process or Working Software?

This framework disregards many result aspects in favor of a progress measure called 'velocity'. Basically 'velocity' displays the amount of work using estimate unit (story points or hours) to show how much your team can do within iteration. In fact, it is really stupid to examine 'velocity' in more detail, because it disregards the whole idea of "working software as a measure of progress" in favor of completely meaningless numbers based on almost nothing.

The main flaw of 'velocity' lies in 'story points' units. The problem is that different teams obviously have different story points estimates (even on the same tasks) and different understanding of story points and their amount. That means, that you can't rate and compare performance between different teams, can you? You are just able to rate someone's ability to provide estimates than actual productivity.

We tend to use the idea of iterations widely, and we are confident that iterative approach is one of the practices that helps us and our customers. The main difference of our iterations from classic Scrum sprints is that we have no problems with hours as estimation unit because we can't agree with redundant advantages of story points unit.

Every task has it's estimate in the project management system, every developer has fixed amount of working hours for particular project. Peak velocity for every week, two or more is clear. Clear and simple.

However, this article is not just about to tell you how scrum is bad, it's about understanding what you may not need from agile and scrum practices. The most important Scrum points are development techniques such as: continuous integration, automated unit testing, pair programming, test-driven development, design patterns, domain-driven design, code refactoring. And these techniques are among those we really pay attention to. Depending on project we can use various combinations, but a must-have pack for us is: continuous integration, automated unit testing, code refactoring.

But this a subject for another article

Hope this topic will help you to make your own conclusions about popular solutions that are not a panacea.