Last week I’ve presented with Herry at LAST Conference about our experience of helping forming a new distributed team in Melbourne and Xi’an while transferring the knowledge of an existing product.

It was an interesting challenge since what we had a not so simple task to do, which was to

  • finish a major release of an existing product
  • ramp down the existing team in Sydney
  • create a new team distributed between Melbourne and Xi’an
  • transfer the knowledge as smoothly as possible, so the new team could start delivering new functionalities as soon as possible

It was great to talk about our experience for the first time, and the amount of questions that came from the audience showed us that it is a interesting (and controversial) topic for other people as well.

The slides are available here, unfortunately it’s hard to get all the content just based on them, but just get in touch with us if you have any.

Advertisements

Last Friday I’ve participated in the Lean, Agile & Systems Thinking conference, which was a one day event organised by Craig and Ed  with the intention to be a day with content “from practitioners” and “to practitioners”.

I have told both of them and a bunch of other people, but it won’t hurt to say again that I believe Australia was in need of an event like this, organised by the community and with focus in providing useful content more than anything. Its success was definitely proven by the attendance and also the twittersphere on the day, so if you haven’t congratulated them yet, don’t wait any longer!

I’m going to try to share what Ive heard around the event here, but there are definitely more places to look for, and videos of some sessions should be available soon.

Storytelling by Shawn Callahan

I’ve started the day by going to the double session from Shawn from Anecdote on business storytelling. I’ve been reading on the subject for a while and the session was very interesting.

After proving in a story telling exercise that everyone has a story to tell (and that we start telling them after we hear other people doing it!), shawn spoke about the storytelling spectrum and how we should keep the business stories on what he called the small ‘s’ version, avoiding the risk of telling something so epic that it makes us lose the engagement of our colleagues.

He also spoke about anecdote circles, where people gather to tell stories about the environment they are in, and gave a few examples and tips on how to create questions that will spark stories from people:

  • Never ask why questions
  • Use when and where
  • Make open questions
  • Ask for an example if answer is too narrow
  • Include emotions, as in “when did you feel like … ?”

Some examples of questions:

  • What have you seen lately that has surprised you?
  • When was the last time that something small made a big difference?

He finished the session talking about a story narrative and how you can construct a story, showing video examples of great story tellers and how they used the elements he was talking about.

Overall a great session, definitely recommended if you have the opportunity!

Cynefin Model by Kim Ballestrin

Kim gave an overview of what the Cynefin model is and how she is using that in her current work.

Having had a brief understanding of the model beforehand, it was really useful to see someone talking about it in action, and what it could be used for.

She gave an example of how the model can be used in classifying types of work, and then using the classification to execute them differently. She used three categories for that:

  • Complex Work (with uncertain outcome) – Create experiment and test it the cheapest way possible, to verify if it’s worth being done
  • Complicated Work (where analysis is required)  – Analyze
  • Simple Work (where outcome is certain)  -Build

She spoke about what an experiment actually is in that context and how it could be just a conversation, giving the example of a kids’ party, where parents are constantly assessing risk and acting on weak signals.

Live Below the Line by Claire Pitchford

Claire spoke about her experience as a business analyst in the Live Below the Line project, where they had to deliver a campaign website in six weeks.

She talked in some detail about the inception process that was performed with the client and the whole team during one week, helping everyone get to a shared understanding of the project, and how different tools as personas, storyboards, stories and estimation where used in the process.

It was a very practical talk about what was done, and also quite impressive that she was happy to talk about everything that went wrong, things she tried and didn’t work but also what she learned during it.

As I mentioned before, it was a great day above all. I also have presented on two sessions during the day, and will write about it in separate posts.

After working in IT for a while, one thing I’ve noticed is that there is a lot of legacy code hanging around. Some companies are better than others in dealing with it, but there are a lot of reasons while code becomes old and very hard to maintain (some discussed here), making it quite a difficult task to keep an organisations’ codebase up do date.

Since every problem must have a solution, legacy code comes hand in hand with “technical” projects,  where the main goal is to rewrite an application (or part of it) in a new technology, or in a “better” way.

There are different reasons for this. Sometimes the company traditionally developed things in a specific technology and has since evolved, leaving behind a few systems that were never updated. Sometimes the original code was developed without long term aspirations (some would say hacked together) and it became more useful than expected, surviving years running in production, but also with high maintanance costs and lacking in efficiency.

Just making it clear, I agree with the need of retiring legacy code. I do believe it’s better not to create it in the first place, but once it’s there, something has to be done. However, these kind of projects come with more risks than usual in my opinion, and as John once told me,

“any project thas starts with a laundry list of problems is not a good project”.

First of all, how can you tell what has to be delivered? If something got to the point of being called legacy code, you can be sure it has stayed a few months (or years!) without being properly mantained and evolved. In the current times, any customer needs that were being solved a few years ago are most likely not current anymore. In other words, if you are rewriting the same thing again you are definitely writing the wrong thing.

Besides the business issues, any legacy code that has been around in an organisation for a decent amount of time has lived in the imagination of most developers long enough for everyone to be sure they know what needs for it to be developed perfectly this time. And as in any technical solution that has no customer goals at the end, teams end up spinning their wheels and polishing the codebase over and over again, until they reach perfection or the money runs out (which, sadly, usually happens first).

But how to approach this by not focusing on the problems to be solved? Go back to the origin and find out what problem you are trying to solve. Then find the customers who care about it and start from there. There is nothing different from any other customer facing project organisations deliver.

Every line of code should exist and be mantained for a reason, and if no reason can be found, then it might as well be deleted.

It is well known that Agile (not sure about the big/small “A” thing, it always gets me confused) has gone mainstream nowadays. With big companies and conferences endorsing it, long gone were the days when you actually had to convince people this was a good idea… and that’s great!

However, with the early/late majority now adopting Agile, we are not talking about small companies anymore, and that means that the challenge is not how to get teams delivering better, but whole departments and organisations. So yes, scaling agile is one of the current challenges, with the preferred approach being the dreaded (at least by me) “Change Programs”.

I don’t believe agile is a fad or just a small team thing, since empowerment, short feedback loops and delivery of results it’s never going to be a fad and isnt IT specific either. There are many other examples, in different industries (errm… Toyota?) which show that the same principles can be applied successfully in a much larger scale, on complete different problems.

The problem begins though, when by scaling agile, companies try to scale the practices, keeping the control mindset, instead of scaling what’s important, i.e. the principles.

It is common to see companies, for example, adopting a hierarchical structure to create multiple agile teams, all “reporting” to a main office, killing most of what was good about the idea.

If agile in the organisation is the challenge, we need to think about empowerment, short feedback and delivery of real results for the whole company. Unfortunately, the more common behaviour is to talk about bigger walls, how to standardise velocity across teams and synchronisation of iterations.

And if we go back to the roots, and look at the manifesto, I believe we can find a good guidance of what can be done:

Individuals and interactions over processes and tools: Instead of scaling processes and tools to control teams, why not increase the ability of individuals to traverse the organisation, making software developers talk to real customers and sales people talk to qa’s?

Working software over comprehensive documentation: Scale by making a working product the final goal, removing the necessity of internal product briefs, extensive training of sales staff and long delivery cycles.

Customer collaboration over contract negotiation: It is actually impressive how this still makes sense now. We just need to change the customer. It’s not the product owner anymore, it’s _the_ customer, the one who buys your product and pays the bills.

Responding to change over following a plan: Feedback, feedback and feedback. Not from a showcase though, but from the market.

Yes, if it feels like you’ve heard these ideas before, it’s because they are not new. Product teams are the way to scale agile in my opinion. Small and independent groups of people that can get to the best results in short iterations with feedback from the market, in a Lean Startup style. The game shouldn’t be about execution anymore, it is about innovation.

Ive been involved in quite a few discussions about shared code lately, mostly because I’ve been working in a team that has developed a set of internal tools that are going to be used across the company. One of the common topics to debate in this area is what happens next?

After the main part of development has been done, who is responsible for mantaining and evolving this shared codebase?

I’ve written a little bit about shared code and I don’t think it is the best solution for most cases, but in a few situations sharing is necessary, so how should we handle it?

As any popular topic, opinions are diverse, but here are my two cents to the conversation:

It depends : )

The way I see it, there are two main types of shared codebases that can exist in a company, and each of them should be treated in a different way.

Components that are not critical for any team

This is the case of the famous “utils” package, or any other component that was once written because someone needed it and then was reused since it was useful for other people. The main characteristic here is that this code doesn’t sit on the critical path of any team/application. In other words, I could choose to use it or not if it fills my needs.

In this situation, I believe that using an open source model is just fine. Think about your packages as an open source library, that someone can use it or not if they want, and if at some point it needs to be maintained or evolved, the people using it can spend some time doing it.

It doesn’t matter that much if they break things or take the codebase in a direction no one expected, since people can always use older versions or just find a replacement for it.

Components that are critical to teams 

Now this is a more delicate situation. If teams depend on your component working all most of the time, I believe the open source model is not appropriate anymore.

As I mentioned before, developing internal applications should also use a customer-centric view, and that takes time and effort. As the number of users grow and diversify, it’s important to have people in your team that can steer the development in the right direction, thinking about the roadmap for the future and also development quality.

Being a critical component, the open source model makes it hard for anyone to own the responsibility to maintain the code, and hard decisions that will have to be made start to get postponed, while patches start happening more and more.

It doesn’t take long until everyone is attached to a codebase that no one really understands and is afraid to change. In other words, legacy is written.

In this situation, the biggest step is to realize you have a product to maintain, and that will cost, as it costs to maintain any product. There is the need for a focused team that can plan the future and guarantee that users are happy with what they are receiving, and avoiding the pain will just guarantee a greater amount of it in the future.

In my current project we are working with automation of deployments, so a lot of our work involves automating builds and (trying) to create a pipeline using build tasks (currently using Jenkins).

One of the things that started to annoy us is that as a standard build tasks are part of the main code repository for an application, even when the tasks itself don’t depend at all on the codebase. In our case, we are using Rake with Ruby, and using RPM’s to deploy, so our Rakefiles would contain tasks that involved testing and deploying RPM’s, but still were included in the application.

I can see the point of keeping the everything related to an app inside the same codebase, but add that to a slow git and gem server, and our build tasks would spend 90% of their time downloading and bundling the application.

So one simple practice that we are trying now is to create a separate repository for build tasks. If all you need is a Rakefile, why do we have to download more than that ?

Just to exemplify how simple it gets…

That’s it. Quite simple, but thought it was worth mentioning!

In different opportunities IT organisations need to develop internal tools/code to be used for its developers. The reasons for it are a lot of times questionable, like in some cases of creating shared code, but there are moments when they are the right option. With the rise of continuous delivery, deployment automation tools is one of the examples where common tools can be useful for a company.

When that happens, internal teams are often assembled to deal with this problem, and create solutions to be used internally. Unfortunately, these teams seem to suffer from a “too much introspection problem”, and often forget lessons learned about product development when going on their mission.

There is a perception that because something is developed internally and “approved” by the head office (after all, they are putting money on it), other people will be much more receptive and understanding about problems and poor customer service.

Since there are no real paying customers and everyone will have to use the tool at the end (at least we hope for), the need for short product iteration and constant feedback doesn’t seem that necessary, plans are made to architect something that could solve all the problems, just not the one that the users are having.

The problem is that, in reality, market laws operate internally to a company as much as they do in the outside world, and poor over architected solutions that are forced upon users are still not a big hit, even between the organisation’s walls.

For real products (the ones that people pay for), the current solution are lean startup techniques and product teams, and I believe the frame of mind when entering the world of internal development should be the same.

Start with a vision, not a complete solution – Even when the problem is supposed to be known and understood, it usually isn’t as much as we hope. Over-architecting is a problem here as in any other software project and the only way to avoid the plan to fail when facing reality is to start small and validate your idea as you go along. Yes, Im talking about a MVP.

Get out of the building – In this case, your users are probably inside the same building, so there are really no reasons to avoid them. Walk around the floor, find the people that you will help with your product and get them to help defining what needs to be executed from your vision.

Iterate fast, close to the customer – Get your solution out there to be used from the beginning. Sit with your users, help them adopt it and treat feedback appropriately (as in hear it and do something about it).

Use metrics, track adoption and problems – Metrics are there to be used, so why not get them to help understanding how your tool is being used and adopted by your colleagues (or not)?

In summary, despite not having paying users, internal software is also supposed to help somehow, and if it doesn’t, it will be left behind and forgotten, so companies should give it the importance it deserves.