Saturday, December 24, 2016

Essential rules for scaling Agile

Scaling Agile
Based on my experiences with scaling agile in different contexts I am the opinion that the following guiding rules serve me well.

1. Do not scale, in most cases it is not necessary. Create well-defined product boundaries with interfaces and most scaling efforts are futile.

2. Do not multi-site. It makes simple things complex, and hard things even harder.

3. You cannot scale what you do not have, i.e. when you have no well-functioning Scrum teams in your organization you should not talk about scaling Scrum.

4. Think products, not projects. This shift in thinking will help organizations a lot in making better decisions.

5. Continuous improvement. Never stop learning, and do not be afraid to stop what is not working.

6. Technical excellence is important for agile teams, but for scaling it is essential.

7. Take a modular approach, there is no one size fits all framework.

8. You need top-down support, i.e. management wants to change their own way of working too.

9. Change the system, then culture and people's behavior will follow.

10. Tackle one product(group) at a time.

11. Feature teams, not component teams.

12. Empower your Product Owner (or similar role) to take the decisions he/she needs to be taking in that role.

13. Building is the easy part. You should think about operating your products as well. DevOps is the way to go.

Read more…

Friday, December 02, 2016

Outsourcing technical competence?

Technical Competence
I have written about technical competence before in the context of Agile Engineering Practices and Three must have Technical Competencies for Scrum Teams. This article will shed some light on a different aspect of technical competency. Outsourcing it.

A number of companies I have worked for have started a large project based on a technology they are not competent in, or even completely unfamiliar with. This fits very nicely in the outsourcing strategy most of them have regarding IT. But does this makes sense?

In my opinion having technical competence (and excellence) in your organization has never been as crucial as it is today. Creating a technology strategy that allows you to not only deal with but take advantage of the increasingly rapid pace of change separates the successful organizations from the obsolete ones.

Some observations I have made when your organization is not competent in a technology that is used for a big initiative:

- Your IT architecture team is dependent on external consultants for creating an architecture. You can have luck with your external consultants (honest, competent, independent), but I have seen the opposite more often (not competent, driven by sales, vendor lockin). Unfortunately, when you have no competence in your organization you have no way of judging before it is too late.

- The cost of implementing new features (your business requirements) are determined by external consultants and/or vendors, and you have no way of judging if these are reasonable or not.

- The decision if certain new features are possible or not are made by external consultants and/or vendors, and you have no way of knowing if these decisions are justified or not.

- You have no healthy team atmosphere during the project. Internal employees always have to ask external ones for their opinion and input. This gives a very strange team dynamic where externals are making all the decisions one way or another (direct or indirect).

- You are not able to support the implemented solution after go-live without help from external consultants and/or vendors. This makes you very dependent, even after the project is finished

- It makes it very hard to switch vendor or implementation partner, because all of the knowledge of the solution is with them, so when you want to switch because you are not happy you have to work a while in parallel with two different companies. Besides the costs, this will give an even worse team dynamic.

- Your best external people can leave the project on a whim because you have no influence on keeping them there. Supplier priorities may not be you, or they just leave your supplier.

In general I am the opinion that when a company is deciding on a certain technology for a big initiative the first thing they should do is hire two or three of the best people they can get, make them internal employees and give them key positions in your project setup (architect, QA, technical project lead). Leverage their experience by not making beginner mistakes, get second opinions on cost and feasibility estimations and get a judgment of skills of external consultants. This will put your organization in the driver seat instead of being driven by others.

Yes, your headcount goes up, and yes they do not work for free, but trust me on this one, this is money well invested and far much cheaper as not doing it.

PS: Although this was written based on a new technology decision, all the above is true for starting an agile project with a technology you know. When your internal employees are not familiar with Unit Testing, Test Automation and Continuous Integration, get people on board that do. You will never make a lasting change in your organization by outsourcing these.

Read more…