They Don’t Always Have To Use Your App

If your app is for a team of users, don’t focus on the app nor the users. Focus on not impeding their interactions. Don’t forget they can talk to each other and think on their own without your app !

If your app is for a team of users, don’t focus on the app nor the user. Focus on not impeding their interactions. Don’t forget they don’t need your app to talk together. They are already doing it. Worst : don’t try to replace live interaction with electronic processes. It’s best for them and cheaper for you.

It was a shiny day of July, the meeting was 3 hours long. The goal ? Prioritizing, specifying and poker planning the next sprint. We made the mistake of scheduling it right after a 8 hour meeting with our key users (sort of day-long presentation/feedback of our latest monthly release). Now we were embarking on the next sprint. We were exhausted and really focused on details.

Examining story after story, we were fighting to make them all fit in the sprint. First mistake.

Second mistake : focusing too much on each story at a time. Loosing the big picture.

The third mistake needs a little back story.

Our application’s goal is to help people who already work closely together to do so with a tablet. They already talk to each other, they are trained to work together. They work this way since 1933 at least.

The user stories were about helping the team leader to distribute roles in his crew. Simple in appearance…

It’s was a nightmare of story dependencies, complex vague specifications, really expensive features.

Why ? We forgot the people the leader has to manage are physically in the room during the use of the feature. Hence all controls, feedback, error-prone specifications we were trying to establish were useless.

Simply by TALKING to each other, the users could work together. We forgot that since the begging. Focusing more and more on the new tool we were building, we forgot the primary human tool : talking.

We saved our velocity and the project budget. But the danger is still around. Don’t forget the most basic human skills instead of trying to replace them all in one app.

Software R&D : Stop Focusing On Technology

Some big companies have centralized development R&D. But sometimes, it’s simply not working.

Start making developers better at choosing instead of choosing for them

Don’t misunderstand me (especialy you my dear colleagues who read this) : we need some kind of normalization in a company with a lot of different quality level developers. But if you focus on technological solutions you’ll risk to miss the point and make yourself useless. Especially on tight budget.

Do Less :

Trying to produce One-Size-Fits-All-In-One-Inegrated-Frameworks
Hiring intrusive consultants for a short term study
Producing Out-of-the-real-world POCs (Proofs of Concepts)
Listening to all exterior vendors that claim to have the best One-Tool-To-Rule-Them-All

Instead Start :

Gathering common needs from different projects already in production or in the making
Emulate innovation by offering a kind of Entreprise Github
Best : go open source and participate to the real world solutions
Organize as many education events as possible. It’s harder but cheaper than buying soon deprecated solutions.
Create an internal StackOverflow to promote help between product departments that never speak together.
Promote User Groups for both external (open source) tools and internals
Look for the best practice, not the average one. For example promote and teach TDD and Continuous Integration.

What matters is not an all in one solution that will deprecate in 2 years, what matters is making the other average developers of your company better.

It’s about education, not technology. It’s not about methodologies, it’s about state of mind.

What Kind Of Lead Developer Are You ?

There are at least 2 kinds of Lead Developer. The Backup and The Coach. A leader is always someone making you progress in your craft. Either by teaching or by showing.

The Backup

He is working in the shadows. He is your safety net. Every commit, every unit test or method, he scrutinize it.

His goal is to soften the difference of levels between other developers. He is quiet and working on tasks you don’t see at first :

repairing or improving a unit test
reordering your files
answering your small questions
taking and applying merging decisions for your
making great utility classes and stacks to accelerate your work on the most visible part of your project

The difference with a simple developer is that he can explain what and why he is doing. Hence, you progress.

Each of his commit is to be looked at. Because they can and should change the way you code.

The Coach

He is spending more time with you than coding on his own. Peer programming with him (either as a pilot or a co-pilot) is a better than 2 months of school.

It can be frustrating for him, just like for the Backup leader; because he is more helping others to code than coding.

He is the guy you look after every time you start the architecture of a new user story. And you should. More visible he also have to be humble yet firm.

You Should Hire Both

They are complementary. There can be many leaders, not just one. And the time spent by the first must be used by the second to educate the team.

Both are the architects of the project, one by example the other by reputation.

I worked with a good combo on an iOS project. And it’s a joy to follow them, through the code, or in peer programming.

And you ? What kind of lead developers did you meet ?

If you still hang on to “features” you are not as Agile as you think

If you still speak about features, or plan to add another sprint to “finish” the backlog : you are not Agile.

On some Agile projects I’ve been working on I noticed an arch reality :

If you still speak about features, or plan to add another sprint to “finish” the backlog : you are not Agile.

One of the first warning I give a new client about Agile projects is the following : your backlog is not a magical whishlist. You can have :

sprints (event with fixed time frame)
a backlog
a board
a scrummaster
a product owner
a daily meeting
and so on

but if you still think the team will finish all your User Stories at the end of the last sprint, you’re gonna have a bad time.

So Agile is a big scam, right?

No. Certainly not. It’s a reality call : if you don’t have enough money to build all you have in mind, you won’t.

And you know what ? It’s a good thing ! Features are not the goal of all this sprinting. It’s about VALUE.

Your backlog is not final. It’s a moving plan. It’s a goal. And User Stories are certainly not features. A US can be composed of many features. Or none sometimes (just a simple analog solution)

There will be delay and lag. Even in Agile of course. And the solution is not to do another sprint. It’s to cut down the number of features and start concentrate on what is really meaningful to users.

If you think I’m to vague start looking a the best product out there : less features but an immense value each time you use it.

Dismount what you already built !

Maintenance is a part of your software value. It has a cost, it represents a debt.

So some final word of advice :

Have some budget dedicated to dismount or erase some features. It increases software quality (with less code base) and increases its value (more stable, less feature creeped soft).

Test Culture Episode 6 : Unit Tests Are Better Than Excellent Specifications

Let me rephrase : GOOD unit tests are better than excellent specifications.

Unit tests actually ARE the specifications.