Nextgov: How do you define transparency?
Fung: My definition is quite a bit different from the conventional wisdom about transparency. A transparency system is designed to allow people to improve the quality of decisions they make in some way, shape or form, and it enables them to improve their decisions to reduce the risks they face or to protect their interests. Some of those decisions are about political accountability but some are in private life, like what food to buy or what doctor to go to.-- Archon Fung, professor at Harvard University's John F. Kennedy School of Government who studies government transparency.
Does your company practice fair pay? Here's what one worker brought to Google and made a difference in transparency at the search giant.
Tell Your Co-Workers How Much You Make! There's no law against it and it increases the chances you'll be paid fairly.
Does the Agile Manifesto imply some form of organizational transparency? I believe so, yes. Here's what Jeff Sutherland has to say about the topic, look for the Individual and Interaction section. Agile Principles and Values by Jeff Sutherland on MSDN.
Scrum's 5 core values list the concept of Openness. Is this not very similar to Transparency?
There are lots of synonyms - visibility, openness, observable, apparent, etc.
Does this value of transparency imply that the information flows in both directions, up and down an organizational hierarchy, from line-workers to managers & directors, as well as from CEO to directors and wage earners also?
Elements of an Effective BacklogGood Journalism is Transparent and Objective by John Zhu
In an agile transformation, one of the first things we work towards is to create an ability to deliver in a predictable manner. As described in our compass and our journey, there is a clear path for organizations that embark on an agile transformation. By becoming predictable, an organization can make and keep promises. In essence, we are working to stabilize the value delivery system.
There are many things that can contribute to an unstable value delivery system. Ready backlog is one of these. The following diagram illustrates three fundamental elements of agile.
Clarity means that we have a system in which the work we’re asking delivery teams to deliver is clear and well understood. Structure means we have created cross-functional teams that have everything necessary to create an increment of working tested software. The ability to see working tested code is how we demonstrate measurable progress.
Our goal is to provide backlogs that are well understood by delivery teams. When we have ready backlog, delivery teams are able to make and meet their commitments. One contributor of instability is that the backlog items are not truly ready but the team chooses to pull them into a sprint anyway. Unready work creates churn for the delivery team, they spend more time trying to figure out what they are supposed to do than actually doing work to deliver. They may guess and build based on their understanding which may be, and often is, flawed.The Definition of Ready
How do we know the backlog items are ready? Through a definition of ready. Most people are familiar with the term “definition of done”, but many organizations I’ve worked with are not as familiar with the definition of ready.
Just as a definition of done is used to create alignment across a delivery team on what it means to be done with a backlog item, the definition of ready provides clarity to a product owner or product owner team on what it means to create ready backlog items. What might be in a definition of ready? This varies but a list of potential items are in the following list:
- All stories must meet the INVEST criteria
- A clearly defined user
- Story has been estimated
- Acceptance criteria with examples
- Acceptance criteria in a certain format such as “given…, when…, then…”
- External information that can provide context such as:
- User journeys that provide context for the backlog item
- Screen mockups
- Architectural drawings
- Business rules
The definition of ready will be specific to an organization and may even vary across the organization. The definition of ready may need to be more inclusive when working with teams that have little domain knowledge. Maybe it is lighter for teams that have deep product knowledge and a long working relationship with the product owner. The real test is to make sure the backlog items have enough clarity so that the delivery teams are able to make a commitment for delivering items within a sprint.
The definition of ready can evolve over time and is a good mechanism to instill new behaviors. Maybe UI mock ups are something that isn’t normally provided but a delivery team believes this is something that is needed. Add it to the definition of ready. If at some point this is just the way work is done, that new behavior now exists, then remove it. Up to you, just make sure it creates clarity on what is expected.
Having clarity in the backlog is a critical element of a value delivery system. It certainly isn’t the only thing that is needed but we find that backlog clarity is necessary for creating a predictable delivery system. Give it a try if you don’t have one and see if it helps.
By the way, here is a job aid that might be useful for crafting your definition of ready. This job aid is designed to provide guidance on how to create clear user stories.
After a period of working too hard, I have been able to attend a few user group meetings this year. A couple of patterns have stood out for me. Patterns that don't feel right, but maybe I am exaggerating? Do you recognise any of these?
- The user group is associated with an agile consultancy.
- The user group event starts with some promotion of said consultancy.
- The user group doesn't have a website or even a meet-up page.
- The user group website is mostly promoting high-value courses.
- Membership is free (just sign up for our mailing list).
- The user group event is mostly attended by beginners
- The only really experienced Agilist present is the group's host.
- The user group events are mostly talks by managers, coaches or trainers (in other words, they are a form of self-promotion).
Ah, plans… They say luck favors the prepared. Axosoft Version 15.3 adds to those prepping efforts. The Release Planner introduces a new way to approach resource allocation for your sprints and releases. Here’s my voice describing the planner with visual detail:Release Planner
To start this tour, click the Release Planner tab; the planner will appear on the right and your items will be in the workspace on the left.Workspace on the left. Release Planner on the right.
The workspace will be filtered by your Organize Panel selection along with any additional filters, grouping, or sorting you have enabled. Use this customization to get a view of all the items up for consideration.
Over on the planner side, select the release from the dropdown menu or create a new release. This section of the Release Planner allows you to:
- Adjust the start date and due date
- Edit your release details
- Add teams or users participating in this release
- Expand or collapse the users and teams
Your release selection will display all the items currently assigned to each of your teams and team members, as well as any unassigned items in the release/sprint. Each team member will have their own section with:
- Number of items assigned to them
- Amount of time already assigned
- Any available capacity
Any items not assigned to anyone will be located under the [Unassigned ] section and you can remove users by clicking the X symbol to remove that team or user. Removing users will leave their items in the release under [Unassigned]. You can also drag items from the left and drop them in above the user/teams to add them to the release. Any items that are already assigned will add that user to the release. You can also reassign items to a different user from within the planner.Drag and drop items to allocate work. Watch the capacities update How do I set user capacity?
Editing a team member’s settings will allow you to set that user’s work days, daily capacity, and vacation days. Any user of the system can update this themselves by navigating to their username in the upper right and then selecting User Options > Capacity.
User capacities roll up to the release capacity you see in the upper right. This visually shows you:
- Total hours assigned to individual users
- Total hours assigned to teams
- Hours left unassigned
- Remaining available capacity
With this knowledge, drag and drop the items from the workspace on the left to the appropriate user or team on the right and watch your release capacity update. If you exceed your capacity, you should get a red warning so that you can adjust accordingly.
Keep in mind, the capacity you define in the release settings will supersede the user capacities that roll up from all your individual users and teams. You are welcome to use just the user capacities or both!One More Update
One last thing, the Daily Scrum has been renamed to “Standup.” Easy enough, right?Daily Scrum is now Standup
Normally these workshops start with the leadership (the stakeholders or shareholders) which have a vision for a product (or project). This time we skipped this activity.
The purpose of the Workshop is to ensure alignment between the leadership team and the Agile Coaches with regards to the upcoming scrum workshop for the team(s). Set expectations for a transition from current (ad-hoc) practices to Scrum. Explain and educate on the role of the Product Owner.
- Create a transition plan/schedule
- Set realistic expectations for transition and next release
- Overview of Scrum & leadership in an Agile environment
- Identify a Scrum Product Owner – review role expectations
- Alignment on Project/Program purpose or vision
- Release goal (within context of Project/Program & Scrum transition)
Once we have alignment on the Product Owner role and the Project Vision we typically do a second workshop for the PO to elaborate the Product Vision into a Backlog. This time we skipped this activity.
The purpose of the Workshop is to educate the Product Owner (one person) and prepare a product backlog for the scrum immersion workshop. Also include the various consultants, SME, BA, developers, etc. in the backlog grooming process. Expected Outcomes:
- Set realistic expectations for transition and next release
- Overview of Scrum & Product Owner role (and how the team supports this role)
- Set PO role responsibilities and expectations
- Alignment of Release goal (within context of Project/Program & Scrum transition)
- Product Backlog ordered (prioritized) for the first 2 sprints
- Agreement to Scrum cadence for planning meetings and grooming backlog and sprint review meetings
Once we have a PO engaged and we have a Product Backlog it is time to launch the team with a workshop - this activity typically requires from 2 to 5 days. This is the activity we did at GameStop this week.
The primary purpose of the workshop is to teach just enough of the Scrum process framework and the Agile mindset to get the team functioning as a Scrum team and working on the product backlog immediately after the workshop ends (begin Sprint One). Expected Outcomes:
- Set realistic expectations for transition and next release
- Basic mechanics of Scrum process framework
- Understanding of additional engineering practices required to be an effective Scrum team A groomed / refined product backlog for 1- 3 iterations
- A backlog that is estimated for 1 – 3 iterations
- A Release plan, and expectations of its fidelity – plans to re-plan
- Ability to start the very next day with Sprint Planning
Images from the workshop
The team brainstormed and the prioritized the objectives and activities of the workshop.
Purpose and Objectives of the WorkshopThe team then prioritized the Meta backlog (a list of both work items and learning items and activities) for the workshop.
Meta Backlog of workshop teams - ordered by participants
Possible PBI for Next Meta Sprint
Possible PBI for Later Sprints
Possible PBI for Some Day
Possible PBI for Another Month or Never
A few examples of work products (outcomes) from the workshop.
Affinity grouping of Persona for the user role in stories
Project Success Sliders activityTeam Roster (# of teams person is on)
A few team members working hardThree stories written during elaboration activity
A few stories after Affinity Estimation
Release Planning: Using the concept of deriving duration based upon the estimated effort. We made some assumptions of the business desired outcome; that was to finish the complete product backlog by a fixed date.
The 1st iteration of a Release Plan That didn't feel good to the team, so we tried a different approach. To fix the scope and cost, but to have a variable timeframe.
The 2nd iteration of a Release Plan That didn't feel good to the PO, so we tried again. This time we fixed the cost and time, but varied the features, and broke the product backlog into milestones of releasable, valuable software.
The 3rd iteration of a Release PlanThis initial release plan feels better to both the team and the PO, so we start here. Ready for sprint planning tomorrow.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Ever heard these from teams before regarding timeboxing?
- “What we do won’t fit into a 2 week window”
- “The nature of our work is too creative for a timebox”
- <<<Fill in your variation here>>>
If you work with agile teams, some variation of these statements will be familiar. I consistently hear new teams say this over and over when I form new sets of teams.
Here’s the deal, the problem is not the time box. In fact, the time box is exposing problems you need to solve!
Let’s check out some examples of the team’s timeboxing complaints above.
“What we do won’t fit into a 2 week window”
An example team that could have this problem is a one that is siloed by discipline. I am currently working with a set of agile data teams that fit this mold. The team members are very much specialists.
- Data Architecture via Modeling and Data Flows
- Data Analysis
- Coding in Scala and Java
- Data Analytics
- Data Warehousing
- Stored Procedures
- Testing and Automation
- And probably a few more things that I don’t even know about
In total these capabilities make up a cross-functional team. Inside that team they typically do these tasks in sequence waiting for each other to finish. It’s no wonder they can’t fit anything into a sprint!
To fix this
This team is finding ways to work in parallel. This feels a lot like design by contract for each of these sequential items.
To make this even faster
The team will generalize a bit more to swarm around work that can’t be broken into the design by contract method.
Swarming will require team members learn how to maintain their specialty while learning how to help out with another capability needed by the team. That doesn’t mean be a specialist in both, keep your sanity. So, “If I know ETL, can I learn to help with Data Analysis or Stored Procedures?”
Let’s take a look at another common one.
“The nature of our work is too creative for the time box”
Regarding creatives… there is a large belief that most every discipline in product development is creative by that discipline.
We all see ourselves that way. There is a natural tendency to want to go somewhere, be creative, and come back with our creation. However, the importance of feedback is never more apparent than in truly creative environments.
Let’s consider a company creating it’s brand identity. The brand is going to have a significant impact on how customers pick and choose the company or a competitor. Even in this environment, we don’t want to have a team go away and comeback with some gold-plated logo that misses the mark after 3 months.
To fix this
Instead we want to see steady progress toward success. By keeping the actual creative property transparent while collaborating around it, we can maintain visibility of the value that is being created and decide when enough is good enough.
Multiple creatives will be taken into the timebox because no one likes to commit to one thing and have it miss after two weeks. That’s too much risk, so they break it down into smaller deliverables. This benefits the “creative” and the customer.
To wrap up
Timeboxing is not the problem. Timeboxing exposes problems and encourages innovation to find new solutions. From our sprints to daily commitments and on to release planning you will find timeboxes everywhere in agile systems. If you use something like the pomodoro technique, it’s in most every part of your day. This is a critical part for teams to realize as a benefit, not a problem.
Many product owners have a tough problem. They need so many of the potential features in the roadmap, that they feel as if everything is #1 priority. They realize they can’t actually have everything as #1, and it’s quite difficult for them to rank the features.
This is the same problem as ranking for the project portfolio. You can apply similar thinking.
Once you have a roadmap, use these tips to help you rank the features in the backlog:
- Should you do this feature at all? I normally ask this question about small features, not epics. However, you can start with the epic (or theme) and apply this question there. Especially if you ask, “Should we do this epic for this release?”
Use Business Value Points to see the relative importance of a feature. Assign each feature/story a unique value. If you do this with the team, you can explain why you rank this feature in this way. The discussion is what’s most valuable about this.
Use Cost of Delay to understand the delay that not having this feature would incur for the release.
Who has Waste from not having this feature? Who cannot do their work, or has a workaround because this feature is not done yet?
Who is waiting for this feature? Is it a specific customer, or all customers, or someone else?
Pair-wise and other comparison methods work. You can use single or double elimination as a way to say, “Let’s do this one now and that feature later.”
What is the risk of doing this feature or not doing this feature?
Don Reinertsen advocates doing the Weighted Shortest Job first. That requires knowing the cost of delay for the work and the estimated duration of the work. If you keep your stories small, you might have a good estimate. If not, you might not know what the weighted shortest job is.
And, if you keep your stories small, you can just use the cost of delay.
Jason Yip wrote Problems I have with SAFe-style WSJF, which is a great primer on Weighted Shortest Job First.
I’ll be helping product owners work through how to value their backlogs in Product Owner Training for Your Agency, starting in August. When you are not inside the organization, but supplying services to the organization, these decisions can be even more difficult to make. Want to join us?
While the DevOps culture has been heavily focused on what tools to use, little thought has been given to what type of workspaces are needed. Ever since the early days of agile, the importance of an informative workspace has been known. Many of the practices around working together, pair programming and the Onsite Customer from Extreme Programming were to enable the rapid flow and visualization of how the team is doing. Other aspects, such as the Big Visual Chart, were included to keep the information flowing. We have made great progress in this category, but we still have more to do.
Now, fast forward to the DevOps Culture. Much like the original agile movement, DevOps is a relatively unique change in the world of work that involves both cultural and technical shifts. It’s just not enough to have cool new tools like Puppet and Chef, or any of the other cool tools that make continuous delivery “a thing.” We need to be able to think about how we are planning our stories. We need to be able to be including acceptance criteria that go beyond just “is it done,” but also all the way to “is it staying done?”
We often run into this as agile consultants. I have often gone to work with a client and their number one concern as we are going through the engagement is “ok, and what do we do on day one of the sprint when we don’t have you here coaching us?” Now, they are fine on their own, but part of the plan is to know what to do after the training wheels are off. Let’s look at that same idea in terms of DevOps Culture. Stories have a very limited life. Once the product owner has accepted the story, we tear it up and throw it away, metaphorically speaking. But that isn’t the end of the story. The software now needs to live and breathe in the big wide world. How do we do that? DevOps is of course the answer, but what exactly does that mean?
Workspaces in the DevOps Culture
As mentioned earlier in this article, the idea of an informed workspace is a valuable tool in our belt for moving deeper and wider into the DevOps culture. Think back to one of the biggest cultural changes called for in the early adoption of agile. Agile called for bringing QA into the room. We aren’t treating QA as a separate team, but part of the team. All of a sudden we are paying close attention to the number of tests that are passing. So now part of our Big Visual Chart is focused on the pass/fail rate of our tests, not just the status of the story itself. This shift took a lot of effort, and I think that if we are honest with ourselves it’s not done yet. But that is an article for another time. We want to take a deeper look at the keys to successfully affecting a further transformation to the DevOps culture. What aspects will really help us do more than just have lots of automated builds that we call done, with no thought to what happens after?
The first step is to think about the cultural changes required. What is it that we will need to change in our thinking in order to make DevOps more than just another buzzword at our shop? The first, and hardest, change is to stop thinking in terms of the “DevOps team”. The whole team is part of Dev and Ops. There just is no wall to throw “finished” product over anymore. It’s all about creating great and long lasting software. There are many steps that we have already taken to get there, but this is one of the biggest. So let’s take a look at the different activities that really make a DevOps culture thrive.
Of course, the first thing one thinks about when discussing DevOps is the activities that support continuous delivery. This means an even higher need for all tests to be automated. Unit tests are merely the start, followed closely by automating your acceptance tests. Having these tests running continuously throughout the day is basically the cost of entry into the DevOps culture. Without a strong continuous integration server, running tests all day and every day, we just can’t be sure that what we are releasing is of a high enough quality to stay healthy in the real world. After that, the art of continuous deployment becomes an additional challenge. Orchestration tools are vital to make sure the right bits get bundled with the other right bits, and then get put where they belong. And then, since we are all part of “keeping the lights on,” we need monitoring tools to help us visualize whether our software really is behaving properly. So yes, there is a definite technical aspect to DevOps.
That’s a lot of moving parts! We need to keep track of where we are. This leads to one of the cool parts of a true DevOps implementation. All those cool monitors that the Ops guys get with the fancy graphs and uptime charts? They come into the room with the Ops people. And we need to add to them. We are going to track story progress from idea to implementation, and then into the wild. My acceptance criteria are going to include things like “must have Nagios hooks” and “will use less then x% of CPU”. And now we have to live up to it. This means it is more important than ever to be able to visualize the entire flow. Our Big Visual Charts need to be able to show us not just how the current iteration is going. They must show us the state of the build server, the state of the various builds and where they are in any of the extended process, such as UAT, etc. And, in the unlikely event of a failure anywhere along the line, or in post-production, we can follow a clear chain of events back to find the problem quickly.
So now we see that, while DevOps is primarily a people problem, there are a lot of technical aspects that enable a strong DevOps culture. The key to success is the union of the people and technical aspects, which in a way make DevOps a Cyborg. In order to balance these two aspects, and in order to keep ourselves from burning countless hours and countless brain cells chasing down all of the moving parts, we need to focus on Information. The more Information that we can have at our fingertips, the more effective we will be. Each team will identify which information is the most meaningful to them, and how best to interpret it. You can bet that this will be in live charts rather than stale reports. Being able to orchestrate the entire flow of a story’s life, from inception to realization to retirement will be much easier if we can visualize each step of the way. If this means our team room might start looking like the command center in war games, what’s so bad about that?
About the Author
Steve has more than 25 years of experience in software development and 15 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
The search for a new software product is hard enough. I get it, I’ve been through it and I’ve helped people through it. Here at Axosoft I am a part of our Sales team so I help people go through this process every day. I have also worked in software support, training and account management in the past so I completely understand the challenges of how to best set a team up for success.
Once you find the product that you think is the answer to all your problems, you have to convince your team it was the right choice. So how do you enlighten those folks and get them on board with the super new product you spent countless hours evaluating, reviewing, testing, asking questions about and negotiating for?
Recently, I had a customer who had a great attitude toward this process and wanted to focus our call on these best practices to be sure his team was successful with the Axosoft product. I think a lot of people could benefit from this advice, so I’m going to share my insights! There is no magic wand you can wave to get everyone on the same page, but here are a few things you can do to at least make it easier.1. Prepare in Advance
Really think through what each of the new users (or teams of users) need to do on a daily basis. Ideally, you will have included representatives from these teams in the evaluation process to provide feedback, but if not, do your best and ask questions. Think about what they do when they come in and how this new product will make that easier for them. Once you figure that out, set up their access accordingly. What does that mean? It means don’t give them access to every little thing the software has to offer, but don’t limit them so much that they can’t actually get anything done.
If you are not sure what a specific role would need, ask someone to be a part of the process. Maybe this is a good chance to pull in someone you think would be a good resource or advocate. Ask him/her to take a stab at setting it up and test it out.
Axosoft Onboarding Tip: Set up your security roles to meet the needs of your user base. Be sure to think through their daily routine and give them enough access to be successful.2. Make it Easy
It’s a good idea, where possible, to set up default views that will make things easier for the new user. Save settings that help even their first log in to make sense (as much as a brand new tool can).
You may also need to update terminology, naming conventions, etc. to match what the user is currently used to. If you use post-it notes on a whiteboard, set up your Axosoft cards and color code them in the same way to make things more familiar. It’s not identical, but it’s going to provide some level of comfort to that new user.
Ideally your new software product is the answer to many of the problems you were looking to solve – but you don’t need to solve them all on day one. What are the critical outcomes of switching to the new product you selected? What are the things that have to be done no matter what? Those are the things you want to train your new users on first. Trying to teach everyone how to tackle every part of a new software solution upfront is probably not going to work out so well, so start with what they need to know and give them some time to work with it. Save the fancy stuff for later once everyone is more comfortable with the basics.
There will inevitably be people who are excited about the potential the new product has – let them help to dictate when it’s time to introduce a new feature or process. Having an advocate on the team is great – it takes some pressure off you and it’s encouraging for the team to see a user like them who is excited about the product.
Axosoft Onboarding Tip: Outline your current process or what you want the new process to be. From there, configure your workflows to meet that basic process and then add in the advanced customization once people get the hang of the product.Summary
Nobody likes change and implementing a new software solution takes some work. These are some of the best practices I have found, but there are lots more – sometimes you just need to step back and think about it for a minute.
Have you recently implemented a new solution (successfully or unsuccessfully)? What tips can you share?
The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.
User stories are great. When you’ve got users, that is. Sometimes, though, the users of a system or product are so far removed that a team struggles to put users into their stories. A sign that this is happening is when teams write stories that begin with “As a developer...” or “as a product owner....”
There are usually better approaches than writing stories like those. And a first step in exploring alternative approaches is realizing that not everything on your product backlog has to be a user story.
A recent look at a product backlog on a product for which I am the product owner revealed that approximately 85% of the items (54 out of 64) were good user stories, approximately 10% (6 of 64) were more technical items, and about 5% (4 of 64) were miscellaneous poorly worded junk.
Since I’m sure you’ll want to know about the junk, let’s dispense with those first. These are items that I or someone else on the project added while in a hurry. Some will later be rewritten as good stories but were initially just tossed into the backlog so they wouldn’t be forgotten. Others are things like “Upgrade Linux server” that could be rewritten as a story. But I find little benefit to doing that. Also, items like that tend to be well understood and are not on the product backlog for long.
My point here: No one should be reading a product backlog and grading it. A little bit of junk on a product backlog is totally fine, especially when it won’t be there long.
What I really want to focus on are the approximately 10% of the items that were more technical and were not written as user stories using the canonical “As a <type of user>, I want <some goal> so that <some reason>” syntax.
The product in question here is a user-facing product but not all parts of it are user facing. I find that to be fairly common. Most products have users somewhere in sight but there are often back-end aspects of the product that users are nowhere near. Yes, teams can often write user stories to reflect how users benefit from these system capabilities. For example: As a user, I want all data backed up so that everything can be fully recovered.
I’ve written plenty of stories like that, and sometimes those are great. Other times, though, the functionality being described starts to get a little too distant from real users and writing user stories when real users are nowhere to be found feels artificial or even silly.
In situations like these I’m a fan of the syntax from the Feature-Driven Development agile process. Feature-Driven Development (FDD) remains a minor player on the overall agile stage despite having been around since 1997. Originally invented by Jeff De Luca, FDD has much to recommend it in an era of interest in scaling agile.
Wikipedia has a good description of FDD so I’m only going to describe one small part of it: features. Features are analogous to product backlog items for a Scrum project. And just like many teams find it useful to use the “As a <user>, I want <goal> so that <benefit>” syntax for user stories as product backlog items, FDD has its own recommended syntax for features.
An FDD feature is written in this format:
<action> the <result> <by|for|of|to> <object>
As examples, consider these:
- Estimate the closing price of stock
- Generate a unique identifier for a transaction
- Change the text displayed on a kiosk
- Merge the data for duplicate transactions
In each case, the feature description starts with the action (a verb) and ends with what would be an object within the system. (FDD is particularly well suited for object-oriented development.)
This can be a particularly good syntax when developing something like an Application Programming Interface (API). But I find it works equally well on other types of back-end functionality. As I said at the beginning, about 10% of my own recent product backlog I examined was in this syntax.
If you find yourself writing product backlog items for parts of a system and are stretching to think of how to write decent user stories for those items, you might want to consider using FDD’s features. I think you’ll find them as helpful as I do.
Communication is the key to solving problems and successfully collaborating, but many of us still have difficulty communicating with particular team members. Why?
Because the words we use mean different things to different people in different contexts.
Matt Badgley, an agile product consultant at VersionOne, recently gave a presentation at Agile Day Atlanta about communication techniques you can use to solve problems and improve team meetings.
VersionOne: Why is it important to focus on the words we use?
Matt: We all know that collaboration is the key to success. Ultimately, solving a problem is generally done by people talking to each other and working things out. Solving problems often happens inadvertently, through conversations.
So that’s why communication is key, and communication is made up, of course, of verbal and nonverbal cues. The same goes for the role of ScrumMaster. So, if you are in the role of product owner or ScrumMaster and you’re not good at facilitating communication, you are not going to be successful. So that’s why it’s really important.
When you actually talk about what words mean, you will find that certain words in certain organizations trigger emotions. They are bad words. They are basically four-letter words that are emotional for people. So you have to be aware of that. You will also find that there are some terms that mean one thing in one context and something totally different in another context. For example, epic is a word we use all the time in agile. And even the word project means different things, and it actually evokes different feelings in people.
VersionOne: In your presentation you shared some fun facts about communication – can you share those with us?
Matt: One of the most interesting statistics is that women speak roughly twenty thousand words per day on average, while men speak on average seven thousand words per day, and we all have around twenty-five thousand words in our active vocabulary.
Generally, we say between one hundred to one hundred and seventy-five words per minute, although we can listen to up to eight hundred. That is why we can often eavesdrop on other people’s conversations and gain insight. Our conscious minds can only process about forty bits of information per second, which includes colors and things like that. However, our subconscious mind, which deals with our motor skills, processes around eleven million.
One last little fun fact: the word that has been shown through studies of the brain to be the most dangerous in the world is the word no – probably because we learn that word at a very early age and get our hands slapped. So if you say no in a conversation, that instantly turns the context of the conversation around, or changes the tone. This just goes to show that the actual words we use are often undervalued and can mean so much more.
VersionOne: What are some of the ways you suggest for people to solve that problem?
Matt: In my presentation I make five suggestions.
1) Don’t redefine the obvious.
For example, when talking about requirements, we often use the word feature or capability. Now the scaled agile framework refers to requirements as a business epic or a feature epic. You’ll hear different terms that people throw out, just simply to change the term. So, be very deliberate on whether or not you need to change a word or not.
2) Be deliberate and intentional.
If you make the decision to change a term, be deliberate and intentional about using it. For example, the Spotify model uses the word squad rather than team. Squad makes you think of the military or a small group that is a subset of a sports team. A team is a bigger composition, but a squad is a smaller and more intentional group of people. By redirecting and changing people to use that term, it has some underlying meaning that’s beyond the word team.
3) Be aware of biases around a word.
Bias is a preconceived feeling around certain words. A funny one to use is the word ScrumMaster. The term master has some bias behind it, some predefined bias that people bring into the room with them. It’s not always perceived how it is meant to be, although ScrumMaster does actually mean the master of the scrum process, the sensei. At the end of the day, that bias can be dangerous. So be aware of the bias.
4) Use domain language.
Use the words that the business uses already. This suggestion goes with number one: don’t redefine the obvious, but also don’t go out of your way to use a word that’s not unique to your industry. Accept and embrace some of the acronyms that are associated with the industry. For example, in the agile industry, we use the term product owner and sprints, so embrace those kind of words.
5) Use visual elements when defining a glossary.
It may sound strange to create a visual glossary, but the idea comes from how we learned words as kids. You learned the word apple because you saw a picture of an apple. Defining ways in which people can not only read the word, but also visualize the word helps things stick.
Check out these posts to learn more about how you can improve your communication by focusing on what words mean.
Zapier is a powerful automation service that can fetch data from hundreds of supported applications and post to your Axosoft account. You can also have new items in your Axosoft database trigger updates and post the new data to any of Zapier’s applications. Each automation point is called a ‘Zap’ and they’re incredibly easy to set up and maintain.
To start ‘Zapping’ now or read more about how it works, check out our Zapbook at any time.
Of course, we use Axosoft for all of our Development and Support teams’ needs (and yes, even Sales and Marketing). However, there are a number of other apps we utilize like Calendars, CRM, Accounting Software, etc. that save us tons of time and effort by integrating with Axosoft. However, if we wanted to integrate a new system, we would take one of our developers away from what they’re doing (making Axosoft rock even harder and louder!) to work on internal operations. What used to take days of a developers time, now can be done by anyone on the team in a matter of minutes.
Another great thing about using Zapier for integration is the ability to change from other tools that you’re using more easily. For example, we often stay with tools much longer than we should because the effort it takes to move to new application, simply because of the development resources it takes to update any integration points to feed into any new applications. But with Zapier, you can just update your existing Zaps and point to the new application – that’s it!
View the full list of potential integrations to see how you can make Axosoft work seamlessly with other tools and services. If you have any questions about our integration, please check out our Zapier Help page, or send us an email at email@example.com.You might also like: