December 13, 2017

What makes an ideal agile team?


In many occasions I am being asked by clients to share my thoughts on how they are (planning to) form their Scrum teams. My recurring comments always are to have the team as small as possible, stable and consisting of full-time individuals, maxing out at 9 persons. Have one or more coaches linked to the teams and make sure that there is a mandated Product Owner.
Make sure that relationships are based on trust and ensure that accountability and responsibility are two aspects addressed organisationally with full support of upper management.

The other day I was asked by a manager of one of my clients to comment on a proposal of one of his vendors. A key vendor that has been under delivering since a very long time, but still considered to be a strategic partner in most of my client's business. The vendor is currently experimenting with a different way of addressing its customers by better aligning its services to the needs of its customers. The vendor is proposing to setup a cross-functional team that will be tasked to deliver relevant products in short cycles.

My client is a little sceptical but willing to give the vendor the benefit of the doubt. As such he's agreeing to become one of the first customers to work according to the new proposed process and is now asking me to see what to look for in the proposal. Being the first customer and thus investing time and effort in amending the current mode of operations with this vendor, there's some head room to 'ask' for specific adjustments to the proposal.

The vendor is going to deliver new products and services in a variety of categories to my client and is proposing to setup a Scrum team. My client now wants to know if there are specific aspects of this team that need to be addressed. Also the role of my client with regard to this team is a point of interest in the negotiations. And obviously the delivery of products and services to my client.

Basically the question is: How should my vendor organise its team in order to better meet our requirements? The answer is reasonably straight forward.

In principle you want to keep a Scrum team as small as possible, that is actually a basic principle. The maximum size for a well-functioning team is 9 people. This has already been discovered by the ancient Romans, no kidding.

I would like to argue to start with 6 or 7 people. Rather 6 than 7 by the way. The reason for this is that otherwise you will get specialisations within the team that come to lie with one person, that will immediately become the SPOC / F, who can not get sick or go on holiday.
The strength of a well-collaborating team lies mainly in the knowledge spread throughout the team as well as complementing personalities of the team. This allows members to challenge, supplement and assist each other. It is a common mistake to see what kind of techniques and technologies you want to use and to find the experts for that. It is a Team and not a Group we're trying to forge. Understand the difference, it's important.

I find the use of FTEs in resource planning of Scrum teams confusing and dangerous. I've seen this plenty of time and it never resulted in anything good. One FTE can be filled in by 1 or more people, and that is what you want to prevent. You want the team to be stable, not only within a sprint but also over sprints. Almost at any cost. Again, I'm not talking about a group but about a Team. And, they must all have an engineering mindset. People who dislike doing things themselves and want to automate everything by definition.

Recently I was asked on the subject within the context of an initiative to start treating an operating environment as a platform, which was going to be treated like a product. With a Product Owner at the helm. And a group of my client's experts was assembled to form the 'Scrum team'. I was asked to provide my thoughts on this setup.

We're talking about server provisioning, networking, identity and access management, firewalls, certificates etc. This team is also going to responsible for operating the platform they're developing. My initial thought is to have therefore functional expertise (provisioning, networking, identity management, loadbalancer, firewalls) and an engineering mindset (automating, monitoring, everything as code), if possible either a senior in one or more functional areas and medior in engineer and vice versa. Depending on the team composition, there may also be a medior / medior combination when there's enough seniority in the overal team. Attitude is more important than knowledge in my opinion. I would therefore always prefer someone who wants to automate, will always test and always asks for insight into production.

I do not see why one would need a full-time Scrum Master, that's probably overkill. Having said that, it seems wise to let the team choose their Scrum Master from the team itself. Add a coach for roughly the first 6 sprints to coach the Scrum Master, even though the Scrum Master might be experienced, it is still good to have a coach. The Scrum Master is therefore someone on the team who also takes on the role of Scrum Master. The team chooses the Scrum Master because it will ensure that its their choice, a choice supported by the team.
The role of the Scrum Master is all about addressing people to the standards and values ​​of the team, but also facilitating them in doing their work. I have seen in various situations that it works very well when the Scrum Master is also facilitating in another supportive role, e.g. as Tool integrator in Continuous Deployment environments.

I told the client that I was missing the Product Owner (PO) in his approach. The PO is relevante because the PO determines what the team is going to work on. That would be the person who talks to the customers about what is needed, etc. The PO is responsible for what this team will deliver. The team is responsible for what it creates, the PO is accountable. These are the two most important aspects.
So a stable team and a PO (outside the team) defining the team's priorities. No one else is mandated to determine what the team is working on, because the PO defines the priorities of the products and features to be developed. The team plans the work. So there, by definition, has to be a lot of trust between the PO and the Team, because the PO must be able to rely on the team's commitment to what they are going to do in a sprint. Here comes the Scrum Master in the picture again. Because he has to make sure that the team does not overcommit.

Here's an interesting aspect, the trust aspect. An aspect I will address in a future post, where I will cover more on metrics and KPI's and the trouble of the user story in this regard.

In my opinion, the role of customers should be not only one of the customer, but also one of the user. This will allow a user-centric approach on developing the platform, and at the same time be very customer aware.

You should look for a future post on stakeholder management and agile processes to get some more insights on this topic.

I told in another case with another client of mine that it makes perfect sense to start treating their Scrum teams as internal startups. Basically consider the PO of these teams as the CEO of the startup and the management team would be the investor. By doing so, there's ample opportunity to experiment and evolve into a value driven minded organisation.
In this particular case I suggested to see if it would be feasible to go along these same lines.

The PO will need to determine what an MVP would be. Something small delivered in short increments, so to quickly find out if something is usable. Start cultivating a mindset where 'Done' means 'In use at a customer!' (Done = Live).
Agile means being able to deal with changing requirements in a timely manner. So here comes the point of view that the PO is a person who has a strong personality and is met with a lot of respect. Somebody that knows what the platform should look like, with a product vision. And the PO will have to be mandated. It should never be the case that the customer can circumvent the PO to get things prioritised.
Again, I told my client to get a coach involved here as well. Even if it is an experienced PO, it is important to be coach. In the beginning intensive, but perhaps later (even after 6 sprints) it may be a bit less. It might be an opportunity to invest in an agile-coach, who will take care of all the coaching work (team, Scrum Master and PO).
Just like the PO is mandated to define what is and what is nog going to be in the platform, the Team and the PO should be granted autonomy and self-reliance. The PO is positioned external to the Team and in case of scaling up the team to two teams I would like to argue that both teams get the same PO.

In this particular setting, one could even consider starting with three small teams of 3 to 4 people who all work on their own part within the platform, three products if you will. A team for provisioning servers, one that works on network and connectivity (including DNS, firewalls, loadbalancers) and a team that focuses on IAM Automation (Directory services for example) and certificates. Combine these teams with a single Scrum Master and a PO with three Teams. Obviously an Agile coach for the whole bunch.

So, concluding: A maximum of 9 individuals, all full-time, in the Team. One of which will assume  the role of Scrum Master. Alternatively, form 3 teams of 3 to 4 full-time individuals with an overarching Scrum Master. In addition, a PO with knowledge of the subject matter and full mandate and an agile-coach.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.


November 17, 2017

In depth security... what when the tables are turned?

With many new initiatives at governments and organisations in the area of security, I see that tables are being turned... and initiatives are lagging. Again.


We all do our best keeping the baddies out of our systems, away of our data. But what if the baddies try to do the same? Trying to keep us out of our systems, away from our data? There's a new threat in town, it's our own systems.

Lately I have been talking a lot with one of the Information Risk Managers of one of my clients. Let's call him Frank, it makes writing this post a lot simpler.
So Frank is a different kind of Information Risk Manager. He's very much involved and active in product development. Frank's not policing, he's establishing policies in stead. Mind that I'm specifically not saying that he's writing policies, instead he's establishing them. Together with those around him that are supposed to live according to these policies, he is ensuring that every step of the way, they're involved. It's pretty cool. Then again, Frank is pretty cool.

Frank and I have been doing a couple of security awareness sessions at the client's site. These sessions revolve around Secure Software Development and the intention of these sessions is making sure that those that are developing the products know that they need to build in security from the start. Yes, we are only looking at IT peeps, even though security is obviously a business concern. Well, one step at a time.

I take it that you're well aware of OWASP's top 10. And likely you've at least heard somebody mentioning the GDPA, General Data Protection Act. And considering you're reading this post, you haven't lived under a rock in the past couple of years, so data breaches like the one at Equifax or Yahoo for that matter should be known facts by you.
I love it when these things are being discussed. Stolen passwords, accounts hacked, social engineering to get into systems. Examples galore to justify all those millions of Euro's and Dollars spend on security. Implementing all kinds of programs at enterprises and organisations. At one client I actually told the ISO (Information Security Officer) that his presentation on the topic leaned towards plain old terrorism considering how she was scaring the CFO to approve her budget request.
Well Frank is not like that. Instead Frank is explaining why awareness is so important. He's addressing it from a business benefit to do in-depth security, privacy by design and so on. I actually had to talk firmly to Frank and have a slide in his deck to convey the amount of vulnerabilities found in our systems in the past couple of months. Just to show that not doing anything is not an option. Reluctantly Frank complied.

At this client, we do threat modeling. We do Privacy Impact Analysis, Business Impact Analysis, etc. We analyse a lot. And we're moving into a way of doing all this such that the developers can keep on becoming more and more agile. Sprint based, epic-by-epic, one story at a time. Ensuring that nobody gets into the systems, privacy sensitive information is encrypted and transaction integrity is ensured.
Nobody gets in, and who's in can't see any data and those that can, won't be able to change is. It's awesome, it's secure. And it's lagging behind today's and more importantly tomorrow's threats.

We're spending so much time to lock things down, in depth, on all levels, by design. Making sure that there're no backdoors, systems are patched. But what about the threat of being locked out yourself?

Data hostage is the new trend. With the advent of biometrics, access to systems by certain individuals becomes more prevalent. Unless it's your iris, you won't get into the server room. Unless it's your fingerprint, you won't be able to unlock the device. With face recognition systems build into operating systems like Windows 10, iOS and Android you only have to look at your screen to be granted access to all that data.

Frank knows about all this stuff as well. Together with a couple of really smart developers he's working on utilizing this new tech to make security more convenient for employees that need to access on a regular basis, sensitive information from their devices. Multi-factor, with biometrics as a second factor is around the corner. It'll be all about what you know (PIN or password) and who the system recognises.

This makes it more and more interesting for cyber criminals to no longer try to get access to your data and instead prevent you to get access to your data. When we rely heavily on the uniqueness of our bodies. By storing precise information about a person's iris, face-metics, fingerprints and in the (near) future a person's DNA, we can ensure that people are uniquely identified. But what is going to happen when that data is compromised? 'Access Denied'.
In today's systems where identification is based on what you know and what you, we are nog focussing on corruption of passwords, PINs or authenticator apps. We're focussing on people not getting in, but we forget about people keeping us out. And when you can't get in, your systems are held hostage. Not only your data, which is typically the target of today's Ransom-ware.

We need to think of new architectures that also consider this aspect of security. It's the availability aspect of security. Data and systems need to be available, but consequently also accessible. Availability is typically associated with redundancy and clustering. Cloning and mirroring. On a more functional level it is associated with the GDPA views on a person's right to always access her data and the right to be forgotten. But what if access is denied? What if you're locked out?

Another interesting feat today is that once security is breached, users need to be informed. But what about the reverse. Your security wasn't breach in the sense that people gained access, but instead people removed your access?

This is new territory for many of us and I don't have a suitable solution for these kind of threats. What I do know is that you'll need to address this from your architecture. And you'll need to involve your Information Risk Manager from day one. And make her tag along full time. Constantly. Just like I talk with Frank on a steady basis. Sharing thoughts, discuss the philosophy of security and challenge each other on everything but mainly on how we can make everybody involved in the process of product development aware of these at times very interesting nuggets of architecture.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.


October 20, 2017

What's the story about those other user stories?

User stories expressing what the Product Owner or her Team want or need are bad practice. The PO delivers, never requests!


Backlogs containing user stories that are catering for the needs and wishes of a Product Owner or Product Team are faulty. These kind of stories are unable to compete with stories that clearly add value to the business. By putting these stories on the PO's backlog compromise the ability of the PO to be successful. Instead these stories should be listed on a second backlog owned by the Team. This will improve the team's sense of autonomy, the Team's relationship with the PO.

In the past 6 months or so I've been actively working with agile teams on their backlogs. Specifically the Product Owners. As you might already know, I consider the Product Owner role as one of the most demanding and challenging roles within an agile environment. You might want to read my post on it, which you can find here. One of the major challenges I'm facing in working on backlogs is getting the Product Owner, and also the Product Team to understand why internal user stories are a bad-practice.

Internal user stories are those stories the PO wants, or the team itself. Most of the time, these are stories where an upgrade of some technology is needed, where technical debt is taken care of, or for example where the Product Owner wants some reporting from the tooling. There're any number of stories on backlogs where it is the Team or the PO in the 'I as a ...' clause of the story. Look at your own backlog and see for yourself.

You might have read my post "Perish or Survive, or being Efficient vs being Effective" on what agile encompasses in terms of motivation, or drive. When you commit to agile practices, you commit to effectiveness and in pretty much all cases you commit to a value-driven approach towards what has the highest priority.

Considering the above, than you realize that in most cases, internal user stories are not really creating value. Mind that you will have to consider the story and not the motivation for the story. Be pure in thought.
This is because of the simpel fact that the user, or customer requires and the PO (and her Team) delivers. That's all there is to it.

All of a sudden it is clear why a story like "We, the Product Team, want to upgrade to the next version of technology such and so, in order to reduce our technical debt" is a no-no on the backlog. Why? Because the user, nor the customer typically doesn't care and shouldn't care about the technology used.
Don't believe me? Well, have the user dictate the version of Ruby on Rails to be used in the development of an iPhone app and listen to what the Team has to say about this. I rest my case.
Having said that, it should also be clear that there is typically a more than valid reason why a Team wants to get rid of technical debt, even suggesting how to get rid of it as well. And in most cases it is related to the request of the user, demanding better stability, performance or security. The Team's story is an implementation aspect and nothing more.

Think about this a bit and then you're bound to see that when the PO or the Team will create their own stories and put them on the backlog, they will need to compete with the stories of the other stakeholders. Stories that add value, for the simpel reason that the stakeholders will ensure a clear value-add because that is what gets the story at the top of the backlog. (Provided the PO will actually prioritize the backlog based on business value and not things like vanity or volume of a voice.)
The last thing anyone should want is have the team's stories be relegated to the black-hole called "Tail-of-the-Backlog".

One of the most common ways of getting the things done, the Team wants done is by allowing the Team to spend some time on other things than stories. Sort of a budget expressed in time, the Team can spend on their own stories. I like to maintain the 80-20 rule here, as it can be applied in pretty much everything related to IT. So 80% of the time is spend on creating value, and 20% on something that is not necessarily adding value. How that 20% is allotted is up to the PO and her Team. Could be a day a week, could be two days during a two week sprint, or possible a full sprint once every five sprints.

I call it budget, because the PO's budget is expressed in time. She has a team available to her, a stable team paid for, for the lifespan of the Product she's owning. Consequently all she has is time to spend. Allowing the Team to work on their own stories, makes perfect sense. This is because the Team itself knows best on what stories are the most valuable. Whether it's the technology upgrade, the refactoring of old code or investigating some new concepts and their applicability.
Once the Team maintains its own backlog of its own stories, there is no need to compete with the stories of other stakeholders, the stories bound more clearly add stories. Moreover, the Team will more so be empowered to autonomously decide how stories are realized. Deciding when it is best to cut corners and when not. All of a sudden, the Team is not only responsible for the product's quality, but also accountable for the technical quality of the product.

The PO's backlog is one expressed in value creation, with the highest priority set to the story (potentially) creating the most value. Allowing the PO to be value-driven. The PO therefore can maintain a backlog consisting of user stories with clear stakeholders. People, not roles, that can be called upon to verify the product's ability to deliver value. And with the opportunity to ask these people beforehand how value is created, what metrics are needed to validate the product's benefits, etc. And of course, the story will contain the name(s) of the people to explicitly invite to the Team's demo of the product.
The Team's backlog at the same time can be prioritized on the account of what will reduce the product's costs the most. Accommodate for future developments as well as operational aspects, etc.

Maintaining both backlogs also strengthens the relationship between the PO and the Team, putting the emphasis on trust, accountability, facilitation and empowerment. The corner stones of agile teams.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.