I read a lot of articles during a week. Some in the morning, during breakfast or on my way to the office.
Some during the lunch time, while having a sandwich or a soup in front of my computer.
Some other interesting readings at night, while reviewing my blog roll posts or summarizing some Twitter channels or Twitter past favorited items.
I rarely comment or reply to these articles. I can agree, disagree or just be in a neutral state of mind in regard of point of views expressed in such articles.
Sometimes, a few of these articles will start a rumination in my brain.
A recent article did (I suggest you read it before continuing with the rest of my article):
7 Agile Best Practices that You Don’t Need to Follow
The author starts his articles listing some agile practices that need to be followed:
- Breaking projects in small releases
- Timeboxing Work in Progress (WIP)
- Relying on working software as measures of progress
- Simple estimating and velocity to forecast team performance
- Working constantly and closely with the customer
- Continuous Integration
- Continuous Delivery
A nice mix of XP ideas, Scrum ideas, Kanban ideas and some other unclaimed or software crafters community generated ideas.
I could not agree more with the author (Jim Bird). These are practices that I also strongly believe in.
Then, he lists 7 other principles that (quote from the article):
‘if you don’t follow them, nothing bad will happen to you and your project will still succeed. And there are a couple that you are better off not following at all.’
Some interesting thoughts about these practices, but you might guess, some of these points of view I do not share nor agree.Here is my two cents on these 7 ‘rogue’ agile practices:
Test-Driven Development (TDD)
The author states IBM and Microsoft had success with this practice , reducing defects density from 40% to 90%. On the other hands, TDD is recognized as a design tool, and studies would have shown the bad side effects of TDD on project/package level.
Jim states that testing is important, it does not matter if you do it at first or at the end.
Some facts I have seen about TDD:
- Developers, after hours or days of programming and debugging to complete a feature, do not have energy and most of all, motivation to write tests against this just completed new features. Most of the time , it took a bit more time than expected, so they want to jump to something new. Hence, it is one reason why tests at the end of the programming life-cycle are not always created and maintained.
- I have not witnessed any projets/package big flaws due to TDD. Maybe the projects I was involved into were not complex enough to witness such bad side effects. However, I can confirm personally that 100% of all the components I wrote were much better designed and programmed due to the thinking involved at first while creating the tests suite.
The benefits of better code (method/class/component) design against some potential package-level design issues are greater.
- Too often, I see developers coding some stuff, then they stop, want to see if the actual state of their code work. So , they either start the full app, wait for it to start, then login, then wait for the home view to appear, click here, then there, then input some data here, click here, and THEN, it hits their breakpoint. They will follow carefully the code flow, checking some variable states and ensuring it enters the correct and forecasted blocks.
So much time spent, only to hit some breakpoints.
Some cleverer programmers, will create some temporary console apps, just to be able to bypass the hassle of starting the full app and passing through all the steps to get to their in-progress component.
Why not, then, create an automated test instead of a temporary console app to manually test and follow your code logic?
Based on (at least) these three observations, I tend to strongly suggest that a dev team should have TDD in mind while building a software. There are a few pitfalls to avoid, but in general, TDD generates better return on investment than collateral damages.
Jim list a few reasons why pair programming isn’t always a good solution or a good way to build code.
Several of these reasons are true and you’ll have a hard time trying to convince me otherwise.
I tend to agree with this quoted statement:
” The true answer is that there is no one answer; that what works best is a dynamic combination of solitary, pair, and group work, depending on the context, using your best judgement. Paired programming definitely has its place.”
My goal as a Scrum Master/Team Lead/Project manager/[insert any leadership/servant role here], is to teach to my team the few benefits that pair programming can have on code quality.
And then, inform the team: it is their responsibility to select when such practice should be executed. In critical code situation, I like to hear : “Oh, this part of the app, we should do it in paired, it is much too important and critical than doing it alone by myself“. This shows that we have, as a team , understood that pairing can bring value, and we have defined the situation which such practice should occur, and finally, we are enough aware to detect such situations. (There are other situations than code criticality for pair programming. This was only to show an example where pairing could be called for).
Emergent Design and Metaphor
Jim states that Agile values Simplicity in the design, but defining an architecture on the fly is foolish and impractical.
He ends up this topic with a statement:
“Agile development methods have improved development success and shown better ways to approach many different software development problems – but not architecture and design.”
This topic is complex.
Having been an architect, and still doing some software programming in my spare-time, I have participated in several projects, where architecture was achieved in different ways.
On one side, you want to avoid this situation:
- An architect will be presented a new project. He will investigate on his side the best solution, think at first of high level pieces, then write blueprints, then slowly work his way down through the details of the solution implementation, to reach, at the end , a kind of framework that the developers will use , in a near future , to build the required application.
Then he disappears (or actually, he is required to do a new architecture, on a new project that just popped up).
You want to avoid such ‘big design up front architecture’.
I strongly believe that architecture is a task, that will need to be executed through all the application building phases (with a stress on the first and middle phases).
I have witnessed good projects, with hands on architects (I just call them programmers with an architecture twist!).
However, you can’t refute the reality and power of ‘Emergence’. Having a good idea of where we should go, but being aware of what will ‘emerge’ is an optimal position, even for architecture. You should have a good global idea, but details should emerge from well directed and constrained complex system (such as a developers team).
Jurgen Appelo (the guy behind the wonderful work of Management 3.0), has very good posts and insights on Emergence. Find here one of the few good ones he posted about Emergence:
Architecture should be a mix of vision, wisdom, knowledge and observation.
You should have a enough knowledge and wisdom to form an initial vision for your app architecture. But enough observation, to let your team (and you!) work a first pass on it, and observes what the best parts emerge from this exercise. And then adjust, advise and constantly review your architecture.
Too many times, architecture is view a pre-project phase. It should not. And architecture should be an activity and not only a role. I tend toward the Architecture owner model . (http://disciplinedagiledelivery.wordpress.com/2012/05/28/the-dad-role-of-architecture-owner/).
However, I also agree that creating an architecure or a design on the fly is a bit foolish.
Might work sometimes, but, my guess is, it will not work often.
Jim shortly talks about the daily standups meetings. He doesn’t seem to find much benefits from this practice, and he states:
“and if they(developers) are grown up enough to ask for help when they need it, then you don’t need to make them all stand up in a room every morning “.
Here I totally disagree with Jim.
Some teams/companies are not agile nor Scrum, but they only execute the daily standups. Very often I have seen immediate benefits from this practice.
The daily standups meetings are made for synchronization and to evaluate what were made previously, and ensure the best work plan of the day, to achieve our timeboxed iteration goal.
Programming and building a software involves a lot of ‘me in front of a screen , staring at lines of code, and thinking how to add, improve , change so it can execute properly so we can deliver adequate software’.
And such task , does not naturally involve, that I communicate constantly with others.
As cooks in a kitchen, we need to constantly synchronize ourselves, but the environment is rarely suitable for a highly collaborative communication.
Look at sports team. Rarely will the athletes arrive just on time for the game, play the game and then go home after the match.
Such high level execution requires preparation, match plan, strategy. They might even want to try some new tricks or shots for tonight.
There are also psychological, team bounding effects of such gather-plan-execute phase.
I much prefer to take 15 minutes at the start of my day so I know for sure I am working on what is the most important thing to do now for the team, for the project.
Better than, just arriving at my desk, checking my mails, remembering where I left yesterday, and then just continue to work on what I though , yesterday, was the most important thing to complete.
There are some pitfalls for such daily standups, but I can only see real good benefits from such activity when correctly conducted, that I strongly suggest that you and your team should follow it.
Collective Code Ownership
Jim shortly list two links where it states that:
Letting everyone work on all of the code isn’t always practical (because not everyone on the team has the requisite knowledge or experience to work on every problem) and collective code ownership can have negative effects on code quality.
I am ambiguous about this topic.
I have no strong opinion.
I tend toward having a kind of ‘soft’ collective code ownership.
The best context I witnessed where this ‘soft’ code ownership :
Everybody can see, access and even change parts of the application parts.
However, the company builds an emergent framework, out of their previous application.
This framework is a bit more ‘guarded’. Everybody, by default, can change the framework code, but it is under high observation. Alerts, reports and stats are generated every time some parts are changed. And it is easily ‘revertible’.If the ‘guardians’ of the framework do not agree with the latest code change, they can come back to the previous state.
Informing all the devs that such part of the code is under strict observation and revision, will slow or even stops the ‘young guns’ to change any parts of the code without good arguments.
So, yes for collective code ownership. With guardians and proper tools and policy to monitor. If you can’t have such context, then, I will tend to say: No to collective code ownership.
Writing All Requirements as Stories
Jim states that ‘There are many different ways to effectively express requirement’.
And user stories is only a format out of several others.
Totally agree with Jim.
Even Scrum do not refer much to ‘user stories’.
It is a ‘Product Backlog Item’ and can take several forms.
However, it should always have acceptance criteria, and having some estimates on efforts, and a business value unit.
The specific format of such PBI (Product backlog Item), should be up to the team.
What formats conveys information in an optimal way for your team?
This format should evolves and improves over your iterations, so it doesn’t get stuck on a specific sub-optimal format.
It can be models, data benchmarks, mockups, screenshots. A mix of several of them.
No format fits all developers’ team in all companies context.
Relying on a Product Owner
Oh , this is attacking the heart of Scrum.
Jim states Having a single point for deciding what needs to be builds, in which order, with all the details required for a team to build it, might create what is called a ‘single wringable neck’.
He refers to two different point of views : The one from Mike Cohn, for a single product owner, and the other one from Mary Poppendieck, clearly against.
Mary got a point, it is not ideal to have such single point of decision and risk for such an important responsibility.
But again, I have seen too much benefits , and seen some way to avoid pitfalls, to not strongly suggest this approach of a single product owner, that should be close enough of the end-users.
It enhances the direct communication between the ‘business’ and the devs.
Middlemen roles between the end-users and the developers should be avoided most of the time.
Also, having two different persons managing money (how much it cost) and scope (what our customer needs) is often creating more problems than it is bringing benefits.
Start with a single product owner.
If he has a hard time dealing with client-facing AND team-facing, then give a bit more responsibility to the team on how to achieve the execution of the backlog . This is not ideal but preferable to the waterfall approach and the traditional project management model.
Out of these 7 agile practices, only ‘Writing All Requirements as Stories‘ is, IMHO, the only agile practices that I would say fits in the ‘agile practice you don’t need to follow’.
Emergent design/architecture along with collective code ownership is up to your team/project/enterprise culture.
The other practices would be a strong recommendation from me.
I mean strong, really strong recommendation.