This time I'm writing a little differently structured blog post. Pierre Godts asked me the following questions at the Scaled Agile Framework group at LinkedIn. The question is related to the SAFe Case Study I wrote some time ago. So let's dive a bit deeper into some topics that were left our of the study.
Can you tell us more about the change at employee level?
The change touched mostly people in the development. Previously all developers (coders and testers) had been in one big group and everyone shared the same supervisor. Work was organized around projects that were resourced from this pool of developers on a monthly basis. Projects were steered by people working in the business units.
After the change people were assigned to (Scrum) teams. Each team was appointed a Product Owner who was a member of a business unit. POs reported to the heads of business units (Chief Product Owners or Business Owners). Teams started to follow scrum way of working. During the same time our internal processes were also identified and written down. Release cycle was set to three months although we knew that we would probably face problems in the beginning.
Each team elected their own Scrum Master who then started to facilitate the events and see that we followed the scrum ceremonies. They were all certified (as were the POs). Scrum Master Community of Practice was also established and Chief Scrum Master started to facilitate it.
At the beginning Scrum Masters participated in a weekly Scrum of Scrums meeting. This was later replaced by a meeting that was between any member of each team. Scrum Masters started to have regular get-togethers where they discussed process related affairs and possible impediments that needed to be raised to company level.
What was their commitment to change? Were employees skeptical or not willing to change?
People are all different. Some were more skeptical and some were more like early adopters. I belong to these guys who usually get excited about new things easily. But generally I'd say people were rather committed to the change. The previous state of the company was not really optimal either so I think there was a really fertile ground for some change.
And as depicted in many change management related books the early and late majority just needed a bit more time and discussion. Maybe with some more coaching the change could have been faster. In our case teams were more or less left to figure out the steps themselves. But maybe we just did it with some luck.
Did some employees got fired?
No. No employees got fired during the reorganization. But some didn't like the new way of working and decided to seek their destiny somewhere else. Some started their own company, some simply changed employer. I claim that quite many of these people had been thinking about the change already for a bit longer while. The reorganization was just the final nail into the coffin.
But one really positive thing is that some people have returned. They have seen the greener grass but understood that maybe it's due to more fertilization...
Were new employees hired?
Yes. The company has been growing and new teams have been established during the past years.
Was there an increase in number of employees?
Yes. Same as previous question.
What about stress level, increased or decreased?
This is tough one. Depends. No-one probably misses the long death marches when we tried to get the release together after a year of development. Or the feeling that if I don't get this feature into the product the customers will need to wait for it for another year. (This would inevitably increase the scope creep and result in not so well tested additions at the really late part of the release cycle.)
But then the other side of the coin is that previously some developers had a really big areas of responsibility. This would mean that you could potentially save the whole company by fixing some issues and get credit from everyone. When you are working in a team, it's usually the team that gets the credit. But I see this again as one inevitable thing that happens when a company grows over certain limit.
What about the budgets/costs, controlled?
Honestly I don't know the answer to this one. Probably the budget was controlled, but it was done in so smooth way that it was never evident. More I would say people didn't take the full benefit of their empowerment. When you have been just a resource and someone else has been managing you or your project for long enough, you don't really understand what it means when your boundaries are removed. It's a slow process to get people to see that "Hey, can I do this? Ok, wow, I can!" And it feels great. As an employee it's a bit scary. But as a supervisor I think it's great to empower others!
Did the use of Jira cause problems/difficulties?
Not really. With our distributed setup JIRA was really an essential tool. I like physical boards and post-its but with multiple sites it's a luxury you can't really afford. And when you accompany JIRA with other Atlassian tools you can get real transparency to the development. You can see whole chain from idea to source code to testing and finally to the product. And with documentation included.
May 18, 2015
May 4, 2015
It Yourself Framework Do
As the saying goes, one picture tells more than 1000 words. Maybe that's why there are these comprehensive frameworks that offer nice pictures that you can click and get even more information. There's one in SAFe. And another one in LeSS. And of course DAD has one too. After checking all these others I was actually a little disappointed that Pragmatic Marketing framework does NOT open up the same way. (Improvement suggestion?)
Since many of these frameworks are copyrighted and no modifications are allowed I'm not going to propose anything like that. But, if you have internal processes or any other information that is dispersed in multiple locations and you would like to visualize them in a similar way with these frameworks I'm going to teach you how to make a poor/lazy man's version of the same. You will need the following tools:
First, create a new presentation and add your favorite to-be-framework-background picture to the slide.
Then add the first hyperlink location. If you want to use really fancy shapes, be my guest, but I'd recommend simple ovals and squares.
Draw the shape on top of your background image. Then modify both Shape Fill and Shape Outline to be invisible (No Fill, No Outline).
After this you simply add an Action to the shape that opens the specific URL. I recommend also using the highlighting to more easily spot the actionable area.
Because I had nothing special in my mind I just used Google to find out what can be found with 'Yoda's Eye'. Turns out there is a metal band with this name. After inserting this link and starting my ppt-presentation the result is the following:
The same step for all your relevant links you repeat and a really actionable internal framework get you will! May the force be with you!
Since many of these frameworks are copyrighted and no modifications are allowed I'm not going to propose anything like that. But, if you have internal processes or any other information that is dispersed in multiple locations and you would like to visualize them in a similar way with these frameworks I'm going to teach you how to make a poor/lazy man's version of the same. You will need the following tools:
- PowerPoint
- Some picture
- Documents located at some internal/external URLs
First, create a new presentation and add your favorite to-be-framework-background picture to the slide.
Then add the first hyperlink location. If you want to use really fancy shapes, be my guest, but I'd recommend simple ovals and squares.
Draw the shape on top of your background image. Then modify both Shape Fill and Shape Outline to be invisible (No Fill, No Outline).
After this you simply add an Action to the shape that opens the specific URL. I recommend also using the highlighting to more easily spot the actionable area.
The same step for all your relevant links you repeat and a really actionable internal framework get you will! May the force be with you!
Apr 12, 2015
What's (Still) Missing From SAFe
Scaled Agile Framework offers a nice collection of Agile best practices. The Big Picture helps to visualize different concepts and ways of connecting them together. But one thing has always bothered me: there's no Customer in the picture. That's why I was positively surprised to read that the new version 4.0 will include also this one missing part.
I guess SAFe is mostly describing practices for the research and development activities. But once the development is completed and it's time to make a release, you usually want to give it to your customers. And in most companies there are functions that operate more closely in the customer front: sales and customer service. In smaller organizations these activities could be handled by product teams, but I assume that in a company that is big enough to benefit from the Scaled Agile Framework, these functions are separate.
Actually, linking the development with sales activities is a non-trivial task. I would maybe first broaden the scope of the Product Management with practices from other frameworks, for example Pragmatic Marketing Framework. For me the sales activities are essentially trying to identify customer's needs, understand their problems and look for solutions to those in co-operation with them. If the current offering can fit the customer's process as it is, that's great. But as good solution could be adding the customer needs to Backlogs and fulfilling them in the future. And developing them together would make sure they fit their needs.
Another addition that I would like to see in SAFe is the role UX and design. In the article about Sprint Execution, there's the DBT (define, build, test) loop. I don't think that's enough anymore. I would like to bring this more towards the direction shown by Lean Startup, Lean UX and Design Thinking. Testing should happen with real customers to validate the hypothesis made before the development. Otherwise the road to hell can be paved with good intentions. You might assume that customers want something, but without testing your idea in practice you could be on a totally different page. (Actually I first missed this SAFe UX article. But I think it should be brought more to the Team level also.)
So those are the couple of additions that I would be glad to see in the future. Without Sales there's no money coming in. And without good UX there's probably no sales.
I guess SAFe is mostly describing practices for the research and development activities. But once the development is completed and it's time to make a release, you usually want to give it to your customers. And in most companies there are functions that operate more closely in the customer front: sales and customer service. In smaller organizations these activities could be handled by product teams, but I assume that in a company that is big enough to benefit from the Scaled Agile Framework, these functions are separate.
Actually, linking the development with sales activities is a non-trivial task. I would maybe first broaden the scope of the Product Management with practices from other frameworks, for example Pragmatic Marketing Framework. For me the sales activities are essentially trying to identify customer's needs, understand their problems and look for solutions to those in co-operation with them. If the current offering can fit the customer's process as it is, that's great. But as good solution could be adding the customer needs to Backlogs and fulfilling them in the future. And developing them together would make sure they fit their needs.
Another addition that I would like to see in SAFe is the role UX and design. In the article about Sprint Execution, there's the DBT (define, build, test) loop. I don't think that's enough anymore. I would like to bring this more towards the direction shown by Lean Startup, Lean UX and Design Thinking. Testing should happen with real customers to validate the hypothesis made before the development. Otherwise the road to hell can be paved with good intentions. You might assume that customers want something, but without testing your idea in practice you could be on a totally different page. (Actually I first missed this SAFe UX article. But I think it should be brought more to the Team level also.)
So those are the couple of additions that I would be glad to see in the future. Without Sales there's no money coming in. And without good UX there's probably no sales.
Mar 24, 2015
Building a New Product
As my opinion about perfect team structure has developed during the past years, so has my understanding of how awfully many different things need to be considered when building a new (desktop) software product.
As a coder I used to think that a random idea is a good starting point for a new feature. I still believe that making a crude and fast proto is a good idea, but there's maybe even better way. Before writing any code, make a sketch. Before implementing any functionality, test the idea with a real customer if possible. Then make variations to the design and iterate again. Do this for a while and you have less code to maintain and better understanding of what you maybe should be doing (Lean Startup and Lean UX).
Instead of just copying files between different computers, you might want to set up a version control system. There are many providers, but I can easily suggest Git. It's free, relatively easy to learn and so widely used that you can get help and skilled Git users easily.
"Well written code is its best documentation". I partially sign this statement but not totally. Useless comments that get out of date are just useless. But there might be general design ideas like what kind of inputs and outputs are expected and how different parts of the product are supposed to communicate together. Usually these higher level characterizations don't change much even though classes and modules can have much shorter life cycles. So some amount of (design) documentation is nice.
I like to promote test-driven development, because then you get a nice set of unit tests and presumably your life will be much easier later. It's like an investment into the future. Of course before you can write tests you need to implement a test framework. Fortunately for many modern languages these are often easily available. But if you are dealing with more exotic playground, you might need to invest a bit more time and effort. Never the less, having a unit test framework is an investment you seriously want to make.
It doesn't harm if testing and test automation is given a thought already at the design phase. You might want to have a tester involved.
If you are not intending to make your product open source (which is of course ok too) you should maybe build some kind of licensing system. There are many possible business models and maybe it also depends on if the users are expected to have internet access or not. But it's also an aspect to keep in mind.
Last but not least, after developing the product for a while you might remember that there should also be a way for the users to install the software. And it might have some prerequisites and dependencies that should be fixed before the happy user is able to start your product. You need an installer (WiX, NSIS, InstallShield). And if you haven't done that yet at this stage, you probably also want to set up a Continuous Integration system.
In addition to these, there are many more useful practices (coding and documentation conventions, manuals, 3rd party libraries, etc.), but I think I'm done here. The main point of this post was that there are really many things to consider when kicking up a new product. And even if you implement these it doesn't really guarantee anything yet. But at least you are not failing because you missed these things. :)
As a coder I used to think that a random idea is a good starting point for a new feature. I still believe that making a crude and fast proto is a good idea, but there's maybe even better way. Before writing any code, make a sketch. Before implementing any functionality, test the idea with a real customer if possible. Then make variations to the design and iterate again. Do this for a while and you have less code to maintain and better understanding of what you maybe should be doing (Lean Startup and Lean UX).
Instead of just copying files between different computers, you might want to set up a version control system. There are many providers, but I can easily suggest Git. It's free, relatively easy to learn and so widely used that you can get help and skilled Git users easily.
"Well written code is its best documentation". I partially sign this statement but not totally. Useless comments that get out of date are just useless. But there might be general design ideas like what kind of inputs and outputs are expected and how different parts of the product are supposed to communicate together. Usually these higher level characterizations don't change much even though classes and modules can have much shorter life cycles. So some amount of (design) documentation is nice.
I like to promote test-driven development, because then you get a nice set of unit tests and presumably your life will be much easier later. It's like an investment into the future. Of course before you can write tests you need to implement a test framework. Fortunately for many modern languages these are often easily available. But if you are dealing with more exotic playground, you might need to invest a bit more time and effort. Never the less, having a unit test framework is an investment you seriously want to make.
It doesn't harm if testing and test automation is given a thought already at the design phase. You might want to have a tester involved.
If you are not intending to make your product open source (which is of course ok too) you should maybe build some kind of licensing system. There are many possible business models and maybe it also depends on if the users are expected to have internet access or not. But it's also an aspect to keep in mind.
Last but not least, after developing the product for a while you might remember that there should also be a way for the users to install the software. And it might have some prerequisites and dependencies that should be fixed before the happy user is able to start your product. You need an installer (WiX, NSIS, InstallShield). And if you haven't done that yet at this stage, you probably also want to set up a Continuous Integration system.
In addition to these, there are many more useful practices (coding and documentation conventions, manuals, 3rd party libraries, etc.), but I think I'm done here. The main point of this post was that there are really many things to consider when kicking up a new product. And even if you implement these it doesn't really guarantee anything yet. But at least you are not failing because you missed these things. :)
Mar 16, 2015
Mental Learnings
In this post I try to summarize what I learned from the final part of Thinking Fast and Slow. I've already written two posts about the subject (here and here), but I still want to share something about it (also I can then later refresh my own memory about these things).
Two Selves
Our mind works in two modes. There's the experiencing self that sits at the drivers seat. Everything that happens, happens to this poor fellow. Then there's the remembering self. After experiencing self has done it's part, remembering self decides how the event will be remembered. And surprisingly, this remembering self makes most of the decisions regarding your future.
When we experience something, we don't really remember the whole event. If you for example think about your past work week or last summer holiday (for Finns that might be many weeks), you don't remember all of it. You remember some moments. And actually if you experience something for a longer time, you don't really pay attention to the length. These two things are called duration neglect and peak-end rule. The book offers painful operations as an example. Afterwards you can't tell if you were in pain for 60 minutes or 80 minutes.
Suppose you go through painful procedure that lasts 60 minutes. Then suppose you repeat the same experience, but after 60 minutes you get painkiller and the operation lasts for another 20 minutes. If participants in these two experiments were asked which one they would repeat, majority would select the latter one. Although this means 20 extra minutes of pain! Are they mad? No, remembering self just doesn't care about the length (nor apparently about the suffering of experiencing self...)
Tip for presenters: aim to have some neat moment in your presentation and try to end with a bang. You will be remembered. Unfortunately it's easier said than done. Here's my attempt from this year's Scan-Agile.
Although people are generally risk averse, there are times when they are willing to take risks. If you are faced with only bad options, you will take risks. Another case is lottery or some other possibility to get a highly improbable big gain.
On the other hand when you are almost sure you will get something (95 percent probability), you are willing to settle for something less if you can get it for sure. Who Want's to Be a Millionaire works like that. You can anytime walk away with some much smaller price. This price increases as you get further in the game. And the bigger the sure price gets, the less tempting it will feel to take the risk of losing everything.
Then an example about possible losses. People don't just buy insurances; they buy ease of mind. Even if there's only a very small probability that your house will burn down, you are willing to get an insurance against that.
Finally, the outcome of an event is not everything that matters. The previous state plays a big role too. If two people have equal pay today you shouldn't simply assume they are equally happy about it. The other one might have received a big salary raise recently. The other one might have been dropped from a higher position and hence suffered a salary cut. Probably the first one feels joy, but other one might be looking for a new job.
I've covered only some things from the book that I found interesting. There's plenty of more. I can truly recommend reading this book. It makes you see things differently.
Tip for presenters: aim to have some neat moment in your presentation and try to end with a bang. You will be remembered. Unfortunately it's easier said than done. Here's my attempt from this year's Scan-Agile.
Sure Thing vs. Gamble
People dislike risk in most cases. In lotteries, people prefer getting sure but smaller gains versus bigger ones with some risk included. But situation depends a bit on how you frame it. 90 percent survivability rate sounds good. 10 percent mortality rate doesn't sound that good anymore. And if you say that 100 persons out of one thousand WILL DIE, that sounds just super bad. Unfortunately we humans are not immune to these framing effects and political and jury decisions can be influenced bending the words properly. On the other hand when you are almost sure you will get something (95 percent probability), you are willing to settle for something less if you can get it for sure. Who Want's to Be a Millionaire works like that. You can anytime walk away with some much smaller price. This price increases as you get further in the game. And the bigger the sure price gets, the less tempting it will feel to take the risk of losing everything.
Then an example about possible losses. People don't just buy insurances; they buy ease of mind. Even if there's only a very small probability that your house will burn down, you are willing to get an insurance against that.
Finally, the outcome of an event is not everything that matters. The previous state plays a big role too. If two people have equal pay today you shouldn't simply assume they are equally happy about it. The other one might have received a big salary raise recently. The other one might have been dropped from a higher position and hence suffered a salary cut. Probably the first one feels joy, but other one might be looking for a new job.
I've covered only some things from the book that I found interesting. There's plenty of more. I can truly recommend reading this book. It makes you see things differently.
Feb 26, 2015
Different Roles in a Full Stack Team
I don't think life is a box of chocolate. But it keeps surprising me never the less. In my case that means that I keep finding value in different activities. Such that I have not done myself or that my teams have not done very much. Maybe it could be best described as evolution.
I started as a coder. Although people didn't say it out loud (often), making modifications to 'the core' was more spectacular than making modifications to the graphical user interface. Mostly the illusion came from the siloed organizational structure. People who do something like to think they are somehow better than those 'other people' who do other things. Which is silly, of course, but still very human. :)
But anyway, I was a core developer. I worked with a big legacy core and could do magical things with it. I could create new features and implement new parts according to the details people gave me. Testing was something that was often mentioned as a valuable thing, but generally praise was given more to people who coded.
At some point I started to realize that testing is, in fact, important. My code wasn't perfect. My mind, the mind of a coder, was thinking how the system should be used. I didn't give a lot of thought to how the system wasn't supposed to be used. But many times users come up with very creative ways of doing things if the tool allows. When someone tested my code, it became better. It had less bugs. So testers were, and still are, useful.
When you work as a group or as a team it makes sense to have someone who makes sure that things happen. I don't think it needs to be a coach or Scrum Master (but it's ok too). More senior team member with right personality and skill-set can be even better.
Then lately, since Apple introduced iPhone, usability has become increasingly important. If the team has a dedicated designer, that's truly awesome. But even having usability built into the working practices is good. It's easy to get carried away with improving the algorithms and trying to write really clean code, but forget the fact that in the end someone should be able to use the system. And hopefully be able to do it without consulting a thick manual. So design and usability are important too.
Finally comes the role of architecture. It's possible to live without named architects, but I don't think it's possible to develop software with multiple teams if the architecture is neglected. Architecture might emerge, but it might not be the architecture you want to see. I dislike the idea of lifting architects to a podium or letting be live in an ivory tower. In my view architect could be a role. For the sake of clarity it would be just good that someone (even if team members take turns) will check occasionally the big picture and make sure all development efforts serve the grand plan. So I consider architects to be important too.
As a conclusion my view of different (necessary) roles in a team has changed over the years. Originally I thought only coders were needed, but now I know it takes a bigger family to grow flourishing software. And in this post I've intentionally scoped out many important business roles. Without proper Product Management and sales there probably won't be anything to develop. But let's leave something also for the future. :)
But anyway, I was a core developer. I worked with a big legacy core and could do magical things with it. I could create new features and implement new parts according to the details people gave me. Testing was something that was often mentioned as a valuable thing, but generally praise was given more to people who coded.
At some point I started to realize that testing is, in fact, important. My code wasn't perfect. My mind, the mind of a coder, was thinking how the system should be used. I didn't give a lot of thought to how the system wasn't supposed to be used. But many times users come up with very creative ways of doing things if the tool allows. When someone tested my code, it became better. It had less bugs. So testers were, and still are, useful.
When you work as a group or as a team it makes sense to have someone who makes sure that things happen. I don't think it needs to be a coach or Scrum Master (but it's ok too). More senior team member with right personality and skill-set can be even better.
Then lately, since Apple introduced iPhone, usability has become increasingly important. If the team has a dedicated designer, that's truly awesome. But even having usability built into the working practices is good. It's easy to get carried away with improving the algorithms and trying to write really clean code, but forget the fact that in the end someone should be able to use the system. And hopefully be able to do it without consulting a thick manual. So design and usability are important too.
Finally comes the role of architecture. It's possible to live without named architects, but I don't think it's possible to develop software with multiple teams if the architecture is neglected. Architecture might emerge, but it might not be the architecture you want to see. I dislike the idea of lifting architects to a podium or letting be live in an ivory tower. In my view architect could be a role. For the sake of clarity it would be just good that someone (even if team members take turns) will check occasionally the big picture and make sure all development efforts serve the grand plan. So I consider architects to be important too.
As a conclusion my view of different (necessary) roles in a team has changed over the years. Originally I thought only coders were needed, but now I know it takes a bigger family to grow flourishing software. And in this post I've intentionally scoped out many important business roles. Without proper Product Management and sales there probably won't be anything to develop. But let's leave something also for the future. :)
Feb 6, 2015
Do the Right Things Right and Fast
It's fascinating how sometimes some relatively simple picture can contain so much relevant information. I have been lately involved in strategy renewal and while doing that I saw a picture that I fell in love with.
My job is very much concentrated around improving software development processes. In essence it's about doing the things right. But many times I have thought that it doesn't really matter if you do things right if they are not the right things. You might write the most beautiful and simple code ever, but it makes no difference if no one cares about it. I feel this is often a problem with some open source projects. Okay, there might be open source with crappy code quality too, but usually the quality is on a really nice level.
Another case are commercial projects with tight deadlines. In those cases it's easily right things (someone, usually customer, is really interested about the results), but just fast. When coders are stretched, it is the quality that suffers.
By concentrating on the software production methods (Continuous Integration, Continuous Delivery) and good engineering practices (craftsmanship), one can only reach adequate results. One dimension is still missing.
Maybe the best non-perfect position to be is when you have a good portfolio (you are doing the right things) and you concentrate on your code quality (doing the things right). At this point you can still miss valuable market windows, but it can still work. Then you can start investing in the production methods and speed things up until you hit the sweet spot in the intersection of all the three dimensions.
Another case are commercial projects with tight deadlines. In those cases it's easily right things (someone, usually customer, is really interested about the results), but just fast. When coders are stretched, it is the quality that suffers.
By concentrating on the software production methods (Continuous Integration, Continuous Delivery) and good engineering practices (craftsmanship), one can only reach adequate results. One dimension is still missing.
Maybe the best non-perfect position to be is when you have a good portfolio (you are doing the right things) and you concentrate on your code quality (doing the things right). At this point you can still miss valuable market windows, but it can still work. Then you can start investing in the production methods and speed things up until you hit the sweet spot in the intersection of all the three dimensions.
I thing this later triplet of circles depicts the situation at practical level. When your Product Management is working properly, your Developers are applying good engineering practices and your development infrastructure is in order, you can expect awesome results. I'm not saying it's easy to achieve but definitely worth a try.
Subscribe to:
Posts (Atom)