I had a great example of how to negotiate and split stories so they are small, achievable pieces of work without being dependent on each other the other day.
One of the teams I’m working with is just starting trying to build a site that will handle the sharing and collaboration of images for design work. I discussed with them the need to have a log-in/security feature and the need for a comments system for the images. The conversation came around to tagging others is a comment and how to best allow that. The team seemed to be getting stuck on implementing the security first then the comments system so that they could communicate with others. While that’s a nice to have that, the dependency makes it less feasible.
So what I suggested was a story that implemented the security piece, and a separate story that built the comments section, without the tagging. Individually they were small enough to build in their sprint and they were not dependent on each other. We can then add another story in a future sprint that does the tagging. This way the dependency in the sprint is broken, and the future story is part of the iteration of the product.
I really like this example because of a few things:
- Keeps the focus on the core product, what does it NEED to do. ( I like to have 3 things )
- Remove dependencies from the sprint so the team can complete work.
- Allow the product to improve in future iterations.
- Negotiate with the team so they understand the main goals and are involved in the decision.
New ideas and new projects really make me happy and a bit excited. The possibilities, journey, and actions are great things to brainstorm and talk about with the team and customers. In agile contexts we present these as epics, themes and user stories, all elements of classic storytelling to try and relate a specific problem to a person and their goals. The storytelling elements go much deeper than that on agile teams and I think nearly everything we do should be in the form of a story.
- For the team:
- Daily stand-ups are the team members story, what trials and success they have uncovered and won or lost.
- Demo’s are a way to tell not only how a story has gone, but a way to link those stories for that iteration together for a larger story that the stakeholders can relate. Presenting the user stories in a priority order or as just work that was done doesn’t get the users involved, these stories are way they will solve their problems and how the solutions flow or relate to one another should matter. Presenting them with a good flow from one to another helps them understand and begin to see how this will change their day/behavior/attitude. Jerry Seinfield had a great line at his Clio acceptance speech about the moment when you first hear about something and then realizing its crap when you get it. The point here is that it is a marketing opportunity, they should be excited or at least interested enough to want what they see. Once they get it ( soon after for an agile team ) they can begin to see if it lives up to what they saw. If not then what went wrong, lets correct it. If we did score, what else can we do?
- In most games, movies, and most other stories is the concept of a “Hero’s Journey”. When you think about your users as the hero’s in their own journey and the application you are creating for them as a way to help them get there is something I really enjoy. Depending on what the problem your application is trying to solve, the users need to either use your app heavily for several hours, check in on it occasionally a few minutes at a time, or only use it when there is an issue. Their interaction with it and their goals should drive the story process.
- In most media situations, the characters are something you observe or inhabit. You relate to them thorough their actions and how you process that reaction. In the agile world, we are trying to help them achieve that goal, even if it’s something you see as mundane as reporting data, or something exciting like a drone network in Africa.
Lately I’ve been working on a project that is envisioned as a “Proof of Concept”. It’s a big important problem, and there is already a good direction in which to try and solve that problem. The current solution is very large, error prone, and unable to scale. However the team has been working isolated from all but a few folks who knew what was needed. We had a very specific end state ( regulatory ) so there was lots of information about what it needed to do at least.
As I’ve been learning and researching the things that the product would do, I was doing it with the local team, lots of public documentation on what it had to do, and some bits and pieces of the current system. Hearing some of the horror stories and issues gave me a lot of context for not only the problem space but what the solution needed to accomplish.
So for a little more than a month we created stories, sprinted, demoed, and iterated on the concepts and ideas we had. It’s the first time I didn’t have customer contact or information from users for a system and it was both freeing and frustrating. Freeing in a sense of anything is possible, just solve the problem. Frustrating from the fact that nobody was telling us if we are on the right track.
We recently did a demo for the larger business / IT team and it looks like we are on the right track. So with that I have some suggestions if you happen to find yourself in this situation:
- Start with what you know.
- If the team already has an idea or you have something firmer than Jello, you can get started. It’ll change later.
- Find out what the end state is.
- Knowing where you need to end up is important. You can change a lot of things along the way to that end goal but you have planned out some ideas.
- Show something to somebody as soon as you can
- Demo to the team, to the management on your side, to other interested people. Get any feedback you can.
- What problem are you trying to solve
- I think this is key. Don’t get bogged down in technology discussions or architecture. What does the product need to do ( 30 sec pitch ) and how can you build a MVP to test that theory.
- Iterate and Learn
- What we’re doing isn’t final, or going to be kept. We have been learning ( new technology ), training ( new folks ), and getting setup to deliver.
- The things we learn will change the system, the 1st iteration will be supplanted by the 4th one. That ‘s more than ok, that’s the best option in the end.
I’d much rather be working with our customers and working on solving their issues, and at some point we will be. Until then, there is always something that can be done to prove your MVP.
I love my pens.
They have been used on every team and project I’ve been on and several times just for my planning or thoughts.
I’m a fan of both low fidelity agile ( cards and stickies ), and drawings in particular. They do come in handy and are of good quality to do some marking around.
However I’ve never used them as props before yesterday. I was speaking with a developer about an idea for a story that would let the users select data to report on. It’s a complex problem to be sure and as I was explaining the idea, he picked up the markers and used them as data elements, he moved them around and showed how you might want to send these colors in one case, and the same colors in a slightly different order with different colors in other cases. I was thrilled to see that the concept was in his head and he was able to tell it back, in his own words, using a tool that clearly communicated he got it. I’m sure the concept will iterate further and be a valuable story for the product, but those moments of discovery are a great part of my job.
It also further cemented the idea that I want to use some Lego’s we have lying around the house to build physical models of ideas ( data elements, sprint plans, story complexity, etc ) and manipulate them on a table instead of a program or on a wall. The interaction, and ability to rapidly communicate concepts and ideas seem like a good way to work.
Unless you happen to be a one man shop or small enough that everybody actually does something on the project/product, you have folks that I’m terming IT here. IT people are the managers for test and development, your manager, and Project Managers or other people who are only involved from a budget or “top level”. Since they are not directly related to the team or product the strategies with them are different. They are no less important, and getting them on board can make your days so much better.
- You are driving the project – The customers, team, and product decisions are driven through you. If you have to ask permission or check-in, you don’t own anything. An opinion from them is fine, a suggestion is allowed, a question is great. An order or threat is not.
- Demos and calls – If your product is being pushed actively you’re doing lots of demos for lots of different folks. Sometimes it’s so they understand what their department is paying for so it can continue, sometimes it’s so they can see progress. I love doing demos of the work that has been done. Doing a quick 10-15 min demo once a week is really cool. If the IT people are willing to attend the regular sprint demos, you’ve really got something useful going.
- Agile Mindset – If your boss or the other people working around you “get it”, life is better. If your boss, or the dev manager want to work a different way then it will be hard if not impossible to be successful. I truly believe that “Culture > Process” and the higher up that goes, the more successful you will be.
- There to help – If the other pieces are easy to work with and act in a supporting fashion then life is easier. Expense reports, time sheets, machine procurement, HR staffing are all pieces that contribute to how quickly and effectively a team can be. The more an organization is built around helping your teams succeed, the more focus is on you and delivery.
- Good communication – The ability of the non-team members to understand and know what’s going on is mostly up to you. The PO has to communicate schedules, roadmaps, issues, and changes to a wider audience so the whole ship can be steered together. If IT folks are asking the same questions or don’t understand something then either you’re not communicating or they aren’t listening.
- Decisions are easy and quick – When the program changes or information is needed, it’s readily available or a short time passes before a decision is made. Open questions that need answers and linger on past the point when you need them is a killer. Good PO’s can help mitigate this by truly understanding the goals and driving factors of the product and making a choice easy for them. I typically will take my best guess at a solution if needed, or have a backup story or idea to implement in case a decision isn’t happening. I’ve not been “totally wrong” before, but I have had to come back and turn slightly once an actual decision is made.
- Leaders – If you are surrounded or involved with actual leaders and not just managers, then fewer issues will be raised. When the entire team and organization are actively following a vision set by a great leader, all activities are lined up and headed in the same directon. The leaders give the people the autonomy and information needed to use their skills to solve that problem. Working for a “why” is important and much better than being directed by somebody higher up.
- Problems – When problems arise or are discovered, everyone should react to solve them or eliminate the need for them. Systemic problems or corporate issues are the only real barriers to the team completing something.
- Micro Manage – When PM’s and other people want to get into the details of how something is being done to make it more “efficient” when they are not producing anything of value, you obviously have issues. Either the trust is not there, they don’t understand how an agile program works, or their default state is to muck around with things. None of this is good and will disrupt the team, the schedule, and cause more time to be spent in meaningless meetings to justify the decisions and actions that were made.
- Fungible assets – When resource managers feel that they can move people between teams on a whim, you will always be forming. Having teams on products grow organically and expand knowledge into new teams with existing members is a good thing and can be timed. If people are removed from your team in the middle of a sprint, because a project is in trouble is BS. It’s happened more than once and I know why it’s done, but I don’t believe that it solves their problem as they believe it will, and damages the team they are removed from.
- Late / Budget / Plan – When people make plans well in advance, without understanding, or involving the people who are doing the work, that plan will fail. It will likely be late, it will likely be over budget, the features will not be there as they thought, and there will be scrambles to understand what will be done to make corrections. Whenever such a fantasy is created at high levels, it should be treated as such. The important thing those things give you is a goal or idea of what needs to be done. It’s worth trying to fit your roadmaps/release plans into that as best you can, but you will never hit it.
- Who needs a team? – If it’s hard to hire the people who you need, or if it takes longer to get them in the door, you can’t compete. If you’re teams boards are not within immediate reach ( i.e. in a separate room they can’t see ) your office functions aren’t helping. If they work in the same office/city and aren’t allowed to sit together, or if you can’t have testers, designers, or other needed people on a team because of reason X, then “Team” is not really something your organization is interested in.
- We bought this, use it – Somebody at some point bought a tool and has mandated that your team use it. Does not matter if it isn’t fit for an agile team/deployment/purpose, you must use it. Free or open source tools that fit better? Can’t use them. Bonus points if IT regularly scans and removed offending programs.
- Divide and Conquer – If the reaction to bad news is to brow beat you or other members of your 1st team until somebody says yes. If the reaction to the changing situation, new discoveries, or data that reverts an earlier theory is to find the needle in the haystack that confirms their bias, then you’re going to be constantly chasing your tail. This also shows up when you tell them “No”, and they go over your head or around you to get the answer they were after. It’s their normal way of working, you are not giving them the answer they want, and you’re not playing ball.
- Who’s running for office? – If office or corporate politics are in play, if one group is being pitted against another group, being sacrificed for a goal, or the hidden goals are running strong you are in trouble. The politics will throw away good products, not promote or select the right people, and hinder the product goal to meet their personal goals. You and the product are simply a resource or means to an end and not something to invest.
In the end, the IT staff can really hinder or dramatically accelerate a PO’s ability to deliver. The teams that are assembled, the organizational constraints, and the noise around the product is their responsibility. If it’s hard to do simple things, or if you are constantly arguing over what’s important you’re going to lose, just a matter of how long it takes. The more agile the organization is, and the more support you get, the better your process and focus will be.
I’m sure there’s a formula out there that says how much time a good PO should spend with the customer. My feeling is that it should be as often as possible, when there is a question, or when you have something to show. Gaining their trust and understanding is critical in an agile delivery, they have to subscribe to the process and way you’re doing things, or you’ll spend valuable time explaining or arguing about those things. Educating them is a tremendous help and though I have had difficult starts with some customers that are transitioning, they do eventually get on board and become your biggest fans.
- Speak the language – When you explain a concept to a customer, they light up and repeat it, they put their own spin on it. Two great examples: 1. Done-Done 2. We can come back to it
- Value – Their focus is on what’s most important, most valuable to them or their clients.
- Feedback – They are responsive to testing/providing feedback early and often during a release.
- Learning – New ideas are generated and added to the backlog with them.
- Pruning – Old ideas are removed or changed as needed, they understand it’s a way off or not worth doing.
- Solve Problems – Their focus is on the problem they are trying to solve, how will it make their life better.
- POC – They call you directly to ask for your help, opinion, suggestions.
- Tradition – They relapse into their old models of delivery and interaction, including not responding unless it’s in a status call ( and if they insist on having status calls).
- Phases – They don’t attend the demos and are not interested in giving feedback before a “testing phase” finishes.
- All or nothing – A mentality that they must have 100% of what they asked for or they can’t be bothered to look at it.
- The PLAN – They keep referring to a @#$! plan that somebody else put together 6 months ago, bonus points if they printed and mounted it for all to see or carved it in stone.
- Decisions – They are constantly changing their minds, like every day. If they can’t pick a somewhat constant direction to head in then you don’t have a moving target, you have chaos.
- Control – If they direct comments back at someone other than you, such as the IT management, or individual team members. This means that they are not interested/comfortable communicating with you and want a middle man or direct control.
- Documentation – Unwilling to negotiate, whatever was written and decided long ago is how it should be done. More focus is on the document than the best solution.
I believe the real difference maker is if the client wants to be involved at a good level or not. If they are too much in the weeds or too removed from engaging with the team then the product or project will surely suffer. A great PO can help eliminate some of that risk by truly understanding why the customer wants this in the first place and making those decisions that a client will not. It’s not the same has having a good customer though. They are a great help.
Ah the product. The thing people argue, worry, and sweat bullets to get out to somebody. No matter what your app does, at some point, it must do it’s intended purpose for it’s higher power. So, what does that look like when it’s going well or if it’s not.
- Consistent – The little things match the other little things. It has a uniform color, behavior, and UX pattern is understood and applied everywhere.
- It Works! – Without any technical oversight, the app is deployed, and able to be used, as is, by reasonable users without falling over or experiencing major issues.
- Answers the why – In the story the why ( or goal ) somebody wants to use your app is important, they want to do something. Can they now that they have your product?
- Iterate/Iterate/?? – Can the app change a part of itself without major surgery? All parts should be able to be changed and changed again if it means it’s a better fit or experience for the user
- Demo/Deploy easily – When it needs to be shown off to somebody, how easy is it? How often can we release code to the environments we have and how often/difficult is it to make it live?
- Performance – the app should perform as intended and without significant delay to execute the desired action. Simple if it’s a website, more difficult if it’s processing something nightly.
- Clean Design – Ideally it would have been designed ( UX ) by a professional that understands good practices. The app should do it’s intended purpose without much flare. Not every screen needs an ok button.
Bad – It’s too easy to say the opposite of all the good list, however true that is. In addition…
- Many Hands – If multiple teams/companies worked on it, can you tell? Did they use different technologies or techniques to put something out? Is it obvious?
- Usage – Are people using it as intended? Metric/analytic programs help show you what the users are doing. Is it easy to find that purchase button or do you lose users at a certain point?
- Documentation – Do they have to read a document or have a degree to understand how to do something? The answer should almost never be “Read the document”
- What was that? – Are there things that catch your eye or does anything happen once in a while? Random things are really annoying ( a recent example – scroll bars appearing or not )
- Loading..Loading.. – Do you click and wait, or do you go to look at a page only to see loading indicators spinning and spinning. Ideally, there’s a performance tweak that could make them go away.
- Up Time – When you want to use it, demo, test, etc are you able to? Does one part of the app going wrong bring down the whole thing? Should it?
- Too Specific – Is it to limited by the environment or tech that was chosen? If the latest code has a major bug, how quickly can it be repaired. If someone leaves the team, would they take all the knowledge with them?
Ideally, as I’m looking at stories during a sprint, getting feedback on a demo or other customer call, the actions and issues are very focused on how to make the experience or task better. The more we are in discussions about issues preventing them from getting to that conversation, the more of an indication the product isn’t meeting their basic needs.
There is a great presentation from Gojko Adzic that includes the “Hierarchy of application needs”. http://gojko.net/2012/11/26/reinventing-software-quality-video/