(a slightly different post published on LinkedIn)
For the past 13 or so years I've been working in a variety of software development shops practicing Agile, and generally some modification of scrum. My focus has always been to take the ideal scrum implementation and continue to make it better - I can say that I've only found a very few shops that practice the "ideal" version of scrum as conceived by the founders of that term. At some point I'll get into that a bit more but the purpose of this article and a few to follow are to take what I've learned most recently from the Pragmatic Marketing training, and apply bits-and-pieces to my current job situation.
First a bit about Pragmatic Marketing.
I believe I first found Pragmatic Marketing in the early 2000's - at the time I was a Director of Technology (my role was more of a Product Manager one, I just didn't realize it yet) for a small start-up that had begun making some headway - in fact we were just turning a profit and had begun to expand the various departments of the company, including Product Management. We hired a very good upper management PdM person who, when presenting his ideas, etc. suggested that we might want to take a look at the materials provided by Pragmatic Marketing (I'll use PM going forward) to guide our expansion plans - at the time you could sign-up for a free PM print magazine that was published, I think either quarterly or bi-monthly and by signing up you had access to the other materials and past issues as PDFs (I may still have those stored in my files somewhere). After reviewing most of what was there we started to employ many of the ideas and also the terms associated with the course - it basically gave us a basis of terminology that was previously missing. Of course, being a start-up it was hard to justify taking the paid-course, but I had always been curios about it.
Next, about the current implementation of scum in my current position.
I function as a Product Manager for two different development groups. The first is a legacy platform that is primarily in maintenance mode, so it's a rather small team practicing kanban and mostly doing user stories relating to reporting needs to compliance and regulatory changes. At some point this team will be absorbed into other efforts, but at present there's enough work to keep them busy. The legacy platform has been running for over 10 years and frankly many of the efficiencies from 10 years ago have been exceeded by company demand which leads to the second group. Group two is a complete redesign using a different technology stack and a common services platform. The second group has gone from one team to five, then shrunk back to a single, consolidated team and now is expanding again into three teams. I share the product owner role with another product manager and we're lead by a Director who acts more as a principal product owner (his focus is more on the strategic direction and he has responsibilities tied to the P&L). From my scale, these newly defined teams are about 70% where I think it should be from a classic scrum perspective (it continues to get better but there's still a bunch of work to do). The group two team started with scrum and was relatively successful up to the initial release of the new product. Recently the expansion of the team into two groups (and building to three) has lead to inefficiencies and our velocity is shot.
A few weeks ago I attended three Pragmatic Marketing courses: Foundation, Focus and Build.
The main thing that I took away from the classes was that I already knew much of the information (you would expect that after 13 or so years doing product, right?) - the classes actually provided a framework of using what I already knew that was a bit more organized. It also provided some insights and approaches that I hadn't tried. Now we get into what I've learned and what I intend to implement to improve our teams.
There was an interesting graph as part of the Build class that I want to share, that has relevancy to what I've so far described. This has to do with context, and how it impacts the effectiveness of teams.
Basically, the first tenant is that the more context a team has the more efficient they become in executing what the market needs.
The better the context, the less that needs to be expressed as any type of requirements for a team - that's not to say that there doesn't have to be documentation, but due to the past shared experiences of the core team, the high trust levels between all participants, and the familiar processes, the teams reacted well, quickly and accurately to requests coming from the market. This is really the ideal state of a good scrum team, where from a PdM perspective, just enough detail is included in a user story. This is well illustrated by the previous velocity of the teams while executing the initial release of the product.
The second tenant is that the less context the team has, the more content and requirements product needs to produce for the team.
The analogy is to take some software feature to a contract shop - because they have very little context, they need much more information in order to be successful - this ends up being lots of artifacts, requirements and specifications. You can see that by expanding our previous team with many new, novice team members we should have adjusted as product managers by providing much more context, to help them ramp up and be successful. By having the unlikely expectations that these newly formed teams would magically become as quick and efficient as the original teams (the idea is to spread the experienced members across the new teams as leadership, so they can impart the technical information needed to get the teams up to speed) within a couple of sprints, we didn't consider that the amount of context provided to the team by product needed to correspondingly increase. So one simple graph and about 5 minutes of discussion in my PM class provided a world of context for me, in first identifying the problem and then taking some steps to improve the situation.
So what to do?
There were several recommendations that I drew from the classwork - remember that the main thing I'm trying to fix is a problem of context - how to get all the business information that product has packed into our brains and disseminate it to the new team members. When I describe a new feature idea I usually use flow diagrams to show how the process could be defined and wasn't spending much time describing the why - I'm now scheduling more time to go over the market need so that the teams are all on the same page. That's a start and seems obvious, but until I recognized that there's a problem how does one improve?
One thing that was emphasized by the instructor, Steve Gaynor (who was fantastic, by the way) was that there was a lot of information addressed in the class, and instead of trying to apply everything, just pick out 2 or 3 things and focus on making them work. So the other classroom idea I found interesting in regards to the problem was the concept of personas.
As with most of my Product Management friends, I usually include the "actor" (a representation of who is interacting with the feature) in my user stories. The concept of persona is a bit different - it's to create a fictitious "who" that's more defined. Using real data (surveys from the market was one suggestion for garnering the information), the product group creates a persona or personas who would represent the most likely candidate(s) for the use of the product. Because there's a lot more information provided as background of the persona, the user becomes more than an actor and the background suggests the needs of the user to the team doing the user story. So instead of "As an admin user" you might say "As Greg Jones" as the beginning of your story statement. There's an entire persona called "Greg Jones" that's been created that represents the characteristics of a typical admin user, including experience with the software and business, background and expertise, the amount of time spent on tasks, etc - whatever is relevant. By expressing personas that can be identified as a real entity, the team has a better experience when developing the feature and thus satisfying or delighting the persona, thereby receiving context from the very beginning of the story. Sounds good, right?
So I started stubbing in the personas for a particular business unit late last week and will continue this coming week. I'll report on this and some of the other ideas that fell out of the PM training in my next post.
-- John Eaton
For the past 13 or so years I've been working in a variety of software development shops practicing Agile, and generally some modification of scrum. My focus has always been to take the ideal scrum implementation and continue to make it better - I can say that I've only found a very few shops that practice the "ideal" version of scrum as conceived by the founders of that term. At some point I'll get into that a bit more but the purpose of this article and a few to follow are to take what I've learned most recently from the Pragmatic Marketing training, and apply bits-and-pieces to my current job situation.
First a bit about Pragmatic Marketing.
I believe I first found Pragmatic Marketing in the early 2000's - at the time I was a Director of Technology (my role was more of a Product Manager one, I just didn't realize it yet) for a small start-up that had begun making some headway - in fact we were just turning a profit and had begun to expand the various departments of the company, including Product Management. We hired a very good upper management PdM person who, when presenting his ideas, etc. suggested that we might want to take a look at the materials provided by Pragmatic Marketing (I'll use PM going forward) to guide our expansion plans - at the time you could sign-up for a free PM print magazine that was published, I think either quarterly or bi-monthly and by signing up you had access to the other materials and past issues as PDFs (I may still have those stored in my files somewhere). After reviewing most of what was there we started to employ many of the ideas and also the terms associated with the course - it basically gave us a basis of terminology that was previously missing. Of course, being a start-up it was hard to justify taking the paid-course, but I had always been curios about it.
Next, about the current implementation of scum in my current position.
I function as a Product Manager for two different development groups. The first is a legacy platform that is primarily in maintenance mode, so it's a rather small team practicing kanban and mostly doing user stories relating to reporting needs to compliance and regulatory changes. At some point this team will be absorbed into other efforts, but at present there's enough work to keep them busy. The legacy platform has been running for over 10 years and frankly many of the efficiencies from 10 years ago have been exceeded by company demand which leads to the second group. Group two is a complete redesign using a different technology stack and a common services platform. The second group has gone from one team to five, then shrunk back to a single, consolidated team and now is expanding again into three teams. I share the product owner role with another product manager and we're lead by a Director who acts more as a principal product owner (his focus is more on the strategic direction and he has responsibilities tied to the P&L). From my scale, these newly defined teams are about 70% where I think it should be from a classic scrum perspective (it continues to get better but there's still a bunch of work to do). The group two team started with scrum and was relatively successful up to the initial release of the new product. Recently the expansion of the team into two groups (and building to three) has lead to inefficiencies and our velocity is shot.
A few weeks ago I attended three Pragmatic Marketing courses: Foundation, Focus and Build.
The main thing that I took away from the classes was that I already knew much of the information (you would expect that after 13 or so years doing product, right?) - the classes actually provided a framework of using what I already knew that was a bit more organized. It also provided some insights and approaches that I hadn't tried. Now we get into what I've learned and what I intend to implement to improve our teams.
There was an interesting graph as part of the Build class that I want to share, that has relevancy to what I've so far described. This has to do with context, and how it impacts the effectiveness of teams.
Basically, the first tenant is that the more context a team has the more efficient they become in executing what the market needs.
The better the context, the less that needs to be expressed as any type of requirements for a team - that's not to say that there doesn't have to be documentation, but due to the past shared experiences of the core team, the high trust levels between all participants, and the familiar processes, the teams reacted well, quickly and accurately to requests coming from the market. This is really the ideal state of a good scrum team, where from a PdM perspective, just enough detail is included in a user story. This is well illustrated by the previous velocity of the teams while executing the initial release of the product.
The second tenant is that the less context the team has, the more content and requirements product needs to produce for the team.
The analogy is to take some software feature to a contract shop - because they have very little context, they need much more information in order to be successful - this ends up being lots of artifacts, requirements and specifications. You can see that by expanding our previous team with many new, novice team members we should have adjusted as product managers by providing much more context, to help them ramp up and be successful. By having the unlikely expectations that these newly formed teams would magically become as quick and efficient as the original teams (the idea is to spread the experienced members across the new teams as leadership, so they can impart the technical information needed to get the teams up to speed) within a couple of sprints, we didn't consider that the amount of context provided to the team by product needed to correspondingly increase. So one simple graph and about 5 minutes of discussion in my PM class provided a world of context for me, in first identifying the problem and then taking some steps to improve the situation.
So what to do?
There were several recommendations that I drew from the classwork - remember that the main thing I'm trying to fix is a problem of context - how to get all the business information that product has packed into our brains and disseminate it to the new team members. When I describe a new feature idea I usually use flow diagrams to show how the process could be defined and wasn't spending much time describing the why - I'm now scheduling more time to go over the market need so that the teams are all on the same page. That's a start and seems obvious, but until I recognized that there's a problem how does one improve?
One thing that was emphasized by the instructor, Steve Gaynor (who was fantastic, by the way) was that there was a lot of information addressed in the class, and instead of trying to apply everything, just pick out 2 or 3 things and focus on making them work. So the other classroom idea I found interesting in regards to the problem was the concept of personas.
As with most of my Product Management friends, I usually include the "actor" (a representation of who is interacting with the feature) in my user stories. The concept of persona is a bit different - it's to create a fictitious "who" that's more defined. Using real data (surveys from the market was one suggestion for garnering the information), the product group creates a persona or personas who would represent the most likely candidate(s) for the use of the product. Because there's a lot more information provided as background of the persona, the user becomes more than an actor and the background suggests the needs of the user to the team doing the user story. So instead of "As an admin user" you might say "As Greg Jones" as the beginning of your story statement. There's an entire persona called "Greg Jones" that's been created that represents the characteristics of a typical admin user, including experience with the software and business, background and expertise, the amount of time spent on tasks, etc - whatever is relevant. By expressing personas that can be identified as a real entity, the team has a better experience when developing the feature and thus satisfying or delighting the persona, thereby receiving context from the very beginning of the story. Sounds good, right?
So I started stubbing in the personas for a particular business unit late last week and will continue this coming week. I'll report on this and some of the other ideas that fell out of the PM training in my next post.
-- John Eaton
No comments:
Post a Comment