Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference.
I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile.
I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about the “right” way to do agile. I like any combination of approaches that help a team deliver value often. I like anything that helps a team to get feedback on their work and their team process.
I like anything that helps management ask the right questions and create an environment in which teams can succeed.
Dogma doesn’t work very well for me. (I know, you are so surprised.)
If you are thinking about your agile approach, ask yourself, “What does agile mean to me? What value will agile deliver?”
Before you decide on an approach, answer that question. You might be more Dan in my most recent Pragmatic Manager, Define Your Agile Success. Once you know what agile means to you, you might start to read more about possibilities that fit for you.
If you are a leader in your organization trying to use agile more effectively, consider participating in the Influential Agile Leader.
Here at Axosoft, we think it’s time for everyone to have TOTAL CONTROL over their repos. So, as of now, with version 0.6 we are in…Open Beta! OPEN. BETA!
Sick and tired of waiting for your dev ‘friends’ to send you an invite? Well, wait no more! Now you can try a truly beautiful Git client right away, because we’ve unleashed the GitKraken beta to the public so now you can dive in all on your own—no friends required! Our initial months in closed beta allowed us to get the app much more stable and feature-rich, and now we’re ready to have the wider world put the app through its paces to further refine GitKraken.
Still not sure what all the hype is about? Enjoy 30 seconds of pure bliss…
Now unleash your repos with GitKraken; simply visit gitkraken.com, hit the download button and install the app. If you were hoping there would be a convoluted setup process involving OS compatibility or dependencies, sorry to disappoint you. As this post covers, GitKraken works without dependencies (you don’t even need to manually install Git on your machine!) and runs natively cross-platform—Mac, Windows and Linux users all enjoy the same user experience.Forking Amazing Bitbucket Support
GitKraken has supported Bitbucket for some time, but you had to manually copy and paste in your URLs to get going. This was unacceptable to the Kraken, and for this release, full integration with Bitbucket is up and running. Interact directly with your public and private repositories and search forks!Get the Keys and Go
That’s not all that has improved with this release. Existing GitHub integration has been tightened up, with the ability to generate SSH key pairs and also automatically add the public key to GitHub. Less app switching FTW.With All the Fixin’s
Apart from the major items, the GitKraken devs have been busy fixing, tweaking, and improving things under the hood to provide better reliability in the app, and have continued to make ongoing UI improvements for a cleaner, more intuitive user experience with as few unnecessary interactions as possible.For the Newbs
There are far too many to list here in their entirety, but a few notable features from earlier releases include:
- Git Flow support: Initialize a workflow per repository then quickly initiate and work on Feature, Release, and Hotfix branches from right in the ref panel
- SSH support: Including support for shh:// protocol format in URLs with OAuth/GitHub
- Drag and drop rebasing
- Undo local actions
- Fast, beautiful UI with intuitive, clean graph view of commits and branches.
If this is your first time using GitKraken, take a look at the release notes and at our introductory blog post, to git familiar with the app’s features. But, there’s no better way to unleash your repos than to try it yourself. We want v1.0 to be the very best it can be, and your feedback and questions are essential to us achieving that. Please follow @GitKraken on Twitter where you can send us your feedback.
So naturally the conversation went something like this:
Inquisitive person: "Hi David, what's an Agile Transition Guide? Is that like a coach?"
David: "Hi, glad you asked. What does a coach do in your experience?"
Inquisitive person: "They help people and teams improve their software practices."
David: "Yes, I do that also."
Inquisitive person: "Oh, well then why don't you call yourself a coach?"
David: "Great question: Let's see... well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching. So do you see why I don't call myself a coach?"
Inquisitive person: "Well no, not really. That's just semantics. So you're not a coach... OK, but what's is a guide?"
David: "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide? What do they do differently than a coach? Did you get to choose your guide, or were they assigned to your group?"
Inquisitive person: "Oh, yeah. I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own. They also had some great gear and lots of local knowledge of where to find the trout."
David: "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."
Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"
David: "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting. Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide. A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."
And now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding. See Richard Feynman's dialogue about "Why questions"
So, I'm not a Coach
I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching). This relationship was typically dysfunctional from the standpoint of being a coach. So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching. It intends the relationship to be vastly different. Since I'm very techie, I appreciate using the correct words, and phrase for a concept. (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things. Two Hard Things)
So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching. Then I needed a new term. And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role. Therefore I coin the term Agile Transformation Guide. But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset. So a transition guide is more generic, capable of the situational awareness of the desire of the organization.
The Difference Between Coaching & Mentoring
Scrum Master vs Scrum Coach by Charles Bradley
challenged my former Head of IT, some years ago. Certainly, it’s a reasonable request to ask how productive a team (or a whole system) is.
But first let’s look at the why behind the question. Why do we measure productivity? Because we should? Because we can? For transparency? Accountability? To drive behaviors and influence culture? Should we measure it at all?
There are three simple, impactful metrics (for Agile or Waterfall workplaces) that I informally collect (through conversations is a good start) to quickly gauge productivity and how healthy and high-performing an organization is.Lead Time
Lead time is the queen of metrics. Lead time tells me how long it takes work to travel through the whole system, from concept to cash:
How quickly is value delivered to customers? Long lead times indicate waste. Lean experts Mary and Tom Poppendieck describe how over 80 percent of time-to-market can be “waste” in the form of delays and non-value-added work. That quickly snowballs into a double-pronged, multi-million dollar cost of delay that directly hits a company’s profits via the delay in value delivered to customers and thousands of wasted person hours.
What do long lead times look like in the real world?
This week I’m working with the largest company of its type in this state. It regularly takes up to six months to get a business case approved, and another 12 months to deliver a project. That’s an 18-month lead time to deliver value to customers. Given that requirements change at an average rate of around 2 percent per month (based on Capers Jones’ empirical research in the 20th century, and it’s probably higher in 2016,) this means a project that goes live today is delivering requirements that were signed off on 12 months ago and have changed (degraded?) by over 24 percent.
This company’s volume of work is expected to increase at least 30 percent in the near future (with no headcount increase.) What happens when we add 30 percent greater volume to an already chockablock freeway? It reduces our speed by an order of magnitude.
This company is adding risk to its portfolio by having such long lead times. Are the teams productive? Not nearly as productive they could be. What actions should they take to reduce lead times? Just reducing the batch size of work (e.g. from 12-month projects into small, discrete features) and setting work in progress (WiP) limits will often double throughput (i.e. halve lead time) as described by Lean management guru Don Reinertsen. These are things you can start doing sooner rather than later.
But, by itself, lead time doesn’t tell me how productive a team is.Predictability
Predictability complements lead time and has an equal seat at the head of the table as the king of metrics. Not only do I want a short lead time, I want to reliably know when work will be done and when value will be delivered to customers. Predictability is not boring—it’s the new black. And it’s sure better than 50 shades of grey, so to speak, in terms of guessing when something might be delivered.
The city I’m working in suffered floods not so long ago. I asked my client, whose offices overlook the river, whether the council knows the volume of water in the river and its rate of flow, i.e. how much water flows into the nearby sea every day. “Of course,” he replied. “So, what about your portfolio? What volume of work can it handle and how quickly will that work flow out to customers?” My client didn’t even pause.We don’t know. We don’t really know what our capacity is at the portfolio level or how quickly we can deliver work.”
That’s not unusual in this type of organization. It would be unusual in manufacturing, where every widget is a physical item and easily traceable. But where work is less tangible it’s easy for “invisible waste” to significantly erode capacity.
Predictable delivery not only increases profits and reduces bottlenecks, it has a more important outcome: it creates trust, trust that teams will deliver on time and that the portfolio can and will deliver the number of features (or requirements) promised. I give my business to companies I can trust—that deliver when they say they will—over companies that don’t deliver when they say they will.
What actions can you take to increase predictability? You need to know the capacity and velocity of your portfolio. Once your requirements are logically grouped into features (see above,) use relative sizing (starting with a small-ish and well-understood feature) to quickly get a view of how much work is in-flight and in the pipeline.
T-shirt sizing is fine if your stakeholders are new to story points (which you can later map over the t-shirt sizes.) It will probably be “way too much” work, which is where prioritization comes in (a topic for another time.) Then, populate “just enough” features to be assigned to the next program increment (say, 12 weeks.) And do this activity with the people close to the work, not far-removed stakeholders.
When I find a company (or a team) with short lead times and high predictability, it’s a good indication that it is productive (although it doesn’t tell me that they are delivering the right things—another topic for another time.) But there’s one other metric that trumps both lead times and predictability.Happiness
Happiness is the most important metric because in a knowledge economy, talented people are the competitive advantage. Are our people (and customers) happy? Simplistically, happy employees deliver good products, which lead to happy customers and good profits. And, the reverse is usually true: an unhappy employee is more likely to deliver a poorer product, leading to unhappy customers and poorer profits. "People, products and profits—in that order,” as our own CA Agile Business Unit GM, Angela Tucci, reiterates. I want to know if my employees are happy or unhappy and why, because it’s closely linked to motivation. As Dan Pink’s now cult classic video explains, give your people autonomy, mastery and purpose and they will be motivated to change the world.
How do we find out whether our people are happy? Ask. Not (just) via an anonymous, annual, online tick box survey. Ask via team retrospectives. Ask via one-on-one or small group sessions. Use a simple 1-5 Likert scale if you want an easy way to quantify the qualitative data. Ask what’s making people happy and unhappy. Frequently improving what’s making people and teams unhappy improves our other two metrics: lead time and predictability.
For example, my client is generally happy but is anxious because the organisation needs to pull 30 percent more work through the “system” as part of its growth objectives. My client’s teams perform reasonably well but are frustrated because there are bottlenecks around key roles and these delays generate significant non-value-added workarounds. Improving these problems would make these people happier and improve lead times and predictability, and lead to happier customers and greater profits.
Let’s return to my former Head of IT and the quest for a single metric for productivity: this may be a holy grail for another explorer. But, armed with metrics for lead time, predictability and happiness, I can reasonably and efficiently infer sustainable productivity—not only at a team level, but at a portfolio and company level.
And so can you.Suzanne Nottage
I met a team recently who was concerned about their velocity. They were always “too late” according to their manager.
I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they “committed” to for each iteration.
This is what their burndown chart looked like.
A burndown chart measures what you have finished. If you look at their burndown, you can see there are times when not much is done. Then, near the end of the iteration, they finish more. However, they don’t finish “everything” before they run out of time.
An iteration is a timebox, by definition. In this case, having to “declare victory” and assess what they were doing should have helped them. But, when this team saw the burndown, two interesting things happened. They beat themselves up for not finishing. And, when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added, not replaced. That meant they never caught up.
They realized they were “late,” off the ideal line from Day 2. They felt worse about themselves.
They stopped doing retrospectives, which meant they had no idea why they were “late.”
A burndown emphasizes what you have completed. A burndown with the “ideal” line emphasizes what you have done and what you “should” be doing. I have used story points here. You could look at story points against time, looking at the available hours or people days or something like that.
For me, a burndown is interesting, but not actionable. Think about what happens when you take a trip. You plug your destination into your favorite GPS (or app), and it calculates how much longer it will take to get to your destination. You know you have driven some number of miles, but to be honest, that’s done. What’s interesting to you is what you have remaining. That’s what a burnup chart helps you see.
I made these charts from exactly the same data. Yet, I have a different feeling when I see the burnups.
When I see the Story points Done without the ideal line, I see a hockey stick. It’s not as bad a stick as the image in Is the Cost of Continuous Integration Worth the Value on Your Program?, Part 1, and it’s still a significant hockey stick.
When I see this burnup, I can tell by Day 3 that we are “behind” from where we want to be. By Day 5, I know we cannot “make up” the time. As any team member, I can raise this as an impediment in the daily standup. If I am a leader of any sort, I will put this on my list to discuss in the retrospective, if not problem-solve before.
Maybe that’s just the way my mind works. I like seeing where we are headed and what it will take to get there. I’m interested in what we’ve done, but that’s in the past. I can’t address the past except to retrospect. I can address the future and say, “Is there something we can do now to help us accomplish what we thought we could in this timebox?”
George Dinwiddie has a great article on burndown charts: Feel the Burn: Getting the Most out of Burndown Charts.
Oh, and the team I discussed earlier? They decided they were trying to cram too much into an iteration. They made their stories smaller. That put more pressure on their product owner, but then they realized lack of PO time was an impediment. They thought they were to blame with a burndown. They saw their data more easily with a burnup. Maybe we all had a mind-meld going on.
It doesn’t matter which chart you generate. It matters how the chart makes you feel: what action will you take from your chart? If it’s not prompting you to act early, maybe you need a different chart. One project truism is: You cannot “make up” time. You can choose actions based on what your data tells you. Can you hear your data?
I came across the idea of mob programming on an Elixir podcast, Elixir Fountain. Its pair programming on steroids, where you sit together and work on one problem together. There’s still just one driver at a time, though it rotates. There’s already a web site and a conference based on it.
I like the concept, but I’m not sure how effective it would be as a constant practice. I’ve done exercises like mob programming in small doses on particularly hard problems that involve architecture choices and occasionally as an exercise at user group meet ups. Anecdotally I don’t see doing it most of the time, but it is possible it works as a regular practice. It’s different enough that it might need some further experiments.
Here's the short answer:
Both are reflective and adaptive. Kanban is focused on limiting work in progress whereas Scrum limits the time you can spend on a problem before you have to produce a result. If your product were a car, Scrum would be saying check your oil and tire pressure every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss. Both the maintenance intervals and the warning lights have value, and it would be silly to ignore either one.
Here's the long answer:
If I remember David Anderson's Kanban course correctly: Every sentence has a subject, a verb, and an elbow directed towards Scrum! OK, I exaggerate slightly ;-) Let's look at this more closely...
What is Kanban?The purpose of Kanban is to create a culture of continuous improvement aka a "Kai-Zen Culture". Kanban does not define a destination, but rather strives to create a culture that is willing to improve.
This essence of Kanban can be summed up in three steps:
- Don't change anything. Change causes fear. Respect people and their roles. So leave existing roles and processes unchanged.
- Agree to get better.
- As a first step to improvement, visualize your work flow.
I believe Alistair Cockburn phrased it this way: Kanban is reflective and adaptive, with reflection and adaption primarily triggered by examining the state of work.
What is Scrum?Scrum is a simple, team-based framework for solving complex problems. Scrum is based on successful patterns for developing products. Scrum implements a small set of patterns:
- Inspect and Adapt at regular intervals
- An interdisciplinary team solves the problem
- The team produces something the customer might value at regular intervals
- One voice speaks for the customers and stakeholders
- A coach helps the team and the organization get better
How are Scrum and Kanban similar?Both are reflective and adaptive. Kanban is focused on WIP whereas Scrum uses Time-boxing. If your product were a car, Scrum would be saying check your oil and tires every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss.
When I listened to David Anderson talking about his case studies, I thought a mature Kanban team is surprisingly similar to a mature Scrum team. What the Scrum Community call sprint planing and review takes on a strategic character, features get done during the sprint., not just at the end of the Sprint. Stories need to be trimmed to size. Scrum has sprints, Kanban has "cadence." You can even limit WIP in a sprint.
How has Kanban influenced my teaching of Scrum?I have recognized a couple of things:
- The easiest route to change starts with an agreement of the parties involved.
- If people look at how they work today, its well represented by Kanban
- If people think back to their best projects, they find a lot of commonality with Scrum. This recognition creates often creates a willingness to try Scrum.
- As it is primarily an attitude and a visualization tool, Kanban is applicable in some contexts where Scrum is not.
- As it is primarily an attitude and a visualization tool, Kanban does not directly address the people issues, especially at the team level.
I have found it most effective to consider Scrum to be a "reference implementation." No one will ever do it exactly like it is in the book, but they should do their best to get as close they can to the reference at the beginning. As they master it, their local improvements may very well take the team away from pure Scrum (think Spotify), but if they are inspecting and adapting frequently, it's OK.
By considering Scrum a point of departure, rather than a Nirvana to be achieved, we take away much of the pressure for compliance. This concept of Scrum as a standard to optimize from rather than a process to adhere to brings it philosophically in alignment with Kanban.
So I don't see an either-or. I use Kanban. I use Scrum. Let's get some work done!
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Is your agile transition proceeding well? Or, is it stuck in places—maybe the teams aren’t improving, maybe the people are multitasking, maybe you are tired and don’t know how you’ll find the energy to continue.
You are the kind of person who would benefit from the Influential Agile Leader event in Boston, April 6-7, and in London, May 4-5, 2016.
Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your business challenges.
If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.
Super early bird registration ends January 31 for London. Our super early bird for Boston is sold out, and the early bird registration is still a steal.
If you have questions, please post a comment or email me. Hope to work with you there.
Scaled Agile Framework® (SAFe®) 4.0 clarifies many aspects of the framework that have been evolving since its inception. It also adds explicit support for the development of very large systems. Even so, you may still be finding your SAFe transformation a little more challenging than you expected.
Here’s how VersionOne can help with your SAFe 4.0 implementation:
3- and 4-Level SAFe
SAFe 4.0 introduces an optional fourth level to explicitly represent the Value Stream. The 4-level model is intended for large systems that realize customer value via the aggregation of features from multiple release trains into a solution.
VersionOne’s n-tier Project Tree enables you to easily create as many organizational tiers as needed. So whether you have a 3-level or 4-level SAFe implementation, or a combination of both models within the same enterprise, it’s just a matter of configuring the Project Tree.
Enterprise Kanban Systems
Multi-level Kanban is an important addition in SAFe 4.0. By having Kanbans at the Portfolio, Value Stream, and Program levels, Epics, Capabilities, and Features can all be visualized and managed for flow and economic benefit.
VersionOne has provided multi-level Kanbans for quite some time. Kanban Boards are configurable as appropriate at each level. By using Kanban boards, you configure your workflows, establish WIP limits to assure flow, provide real-time visibility for work in process, and drill into the underlying details as needed.
SAFe 4.0 also recognizes Kanban at the team level. By using TeamRoom™, VersionOne makes it easy for Kanban teams and iterative teams to coexist and collaborate within the same program.
Capabilities & Enablers
SAFe 4.0 has introduced two new portfolio item types: Capabilities and Enablers. Capabilities are aggregations of Features, and are the means by which solutions are delivered to customers at the Value Stream level. In VersionOne, a Capability is simply a Portfolio Item type. Configuring a Portfolio Item type is easy, and includes the ability to distinguish one type from another by color.
Enablers are technical undertakings that support Stories, Features, Capabilities, and Epics. Enablers may be found at all levels, so you might have Enabler Epics, Enabler Capabilities, Enabler Features, and Enabler Stories. Each of these can be configured as a Portfolio Item type or Story type. Some organizations prefer to keep their type lists as lean as possible, and opt to use a custom field to designate a Portfolio Item or Story an as Enabler. Either way will work.
Communities of Practice
SAFe 4.0 refers to Communities of Practice as “informational working groups designed specifically for efficient knowledge sharing and exploration across teams and groups of professions”. The idea is that as people become distributed across different teams and value streams, there needs to be a way to keep them connected. If “Communities of Practice” is too formal for your liking, Spotify’s “Chapters” and “Guilds” are different ways of expressing the same thing.
VersionOne Communities support your Communities of Practice by allowing people to communicate and collaborate on shared knowledge and “better practices” within the VersionOne platform.
Communities may also be used by your organization’s Agile Center of Excellence (or similar) to communicate guidance that applies across Teams, Programs, Value Streams, or Portfolios.
Although not new with SAFe 4.0, Strategic Themes are a key factor to succeeding with SAFe – especially with very large systems. That’s because they are the high-level enterprise business objectives that guide and constrain portfolio-level investment.
Once you’ve created your Strategic Themes in VersionOne, you can identify and group your Epics by Strategic Theme. Then, using VersionOne Budgets, you can make specific capacity, currency, or percentage allocations to your Strategic Themes, and then track progress against those allocations.
SAFe 4.0 advocates the allocation of budgets to Value Streams. VersionOne Budgets allow you to do just that. Budgeting can be allocated in terms of specific quantities of capacity or currency, or in terms of a percentage of the total. As work progresses, visualizations allow you to easily compare actuals to your planned budget.
As mentioned earlier, Budgets may also be allocated by Strategic Theme.
VersionOne also enables you to distinguish between work related to capital and operational expenses at any level that you need to track them. This facilitates CapEx and OpEx reporting.
VersionOne facilitates building quality in via its native Acceptance Test and Regression Testing capabilities, as well as its support for a wide selection of TDD, BDD, and ATDD tools.
SAFe 4.0 emphasizes agility and coordination throughout the enterprise. To enable the effective flow of value, software delivery and deployment processes must be tightly integrated across Teams, Programs, and Value Streams. In addition, as release batches become smaller, release velocity increases, and Value Streams become more complex, the ability to easily track and automate the flow of value all the way through production deployment becomes increasingly crucial.
More than simply DevOps automation, VersionOne Continuum™ is an enterprise-scale continuous delivery solution for orchestrating and visualizing the flow of change throughout the software delivery cycle. For an in-depth look at VersionOne Continuum, take a look here.
VersionOne is a Scaled Agile, Inc. Gold Certified Partner in both the Agile Tooling and Services categories. In addition to extensive support for SAFe 4.0, VersionOne’s Services team delivers training and consulting services through certified SAFe Program Consultants to help organizations implement and succeed with agile and the SAFe framework.
Interested in learning more? Join Dean Leffingwell for a free webinar to learn what’s new in each level of SAFe 4.0. Click here to register.
Continuum is a trademark of VersionOne Inc.
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.
Ponder this scenario…
Suppose you have an Agile team building applications based on data API’s that are managed by a services team. Suppose that you cannot change the structure of the organization. If changes are needed to get a different data field from the API in support of a feature in your app — what do you do?
The answer is a cross-team story. A cross-team story is really two parts: the validation piece of the story stays with the team that identified the need, and the actual development work story goes to the team that completes the work.
If both teams are running in Sprints, the shortest timeframe for completion of a cross-team story is two sprints. One sprint for the team doing the work, and one sprint for the validation of the team that identified the work.
A cross-team story workflow may look something like this:
1. During release planning or sprint planning, a team identifies work that must be delivered by a different team.
2. The team identifying the work creates two stories.
3. The product owners of the respective teams negotiate priority and scope of the story.
4. The team doing the work plans the story into their sprint. If the team doing the work uses a Kanban methodology, sprint planning is skipped and an expected date is communicated to the identifying team.
5. After the work is complete, the identifying team plays their validation story. This story could have been scheduled in a sprint based on the sprint, or an expected date from the work team.
6. When cross-team stories are identified prior to release planning there is an opportunity to play risk cards to ensure both teams are aware of the priority of the story, and the dependency can be manager by the Program Team or Portfolio Team. The tracking of the dependency can be accomplished in the Scrum of Scrums meetings.
In most organizations cross-team stories are rare. Many cross-team stories increase the risk of delay in delivery. If you notice that your team is always dependent on other teams to complete any functionality, this may be an indication that the skill set or architecture is not aligned with business priorities. This misalignment should be escalated to the Portfolio Team for resolution.
I am shepherding an experience report for XP 2016. A shepherd is sort-of like a technical editor. I help the writer(s) tell their story in the best possible way. I enjoy it and I learn from working with the authors to tell their stories.
The writers for this experience report want to pair-write. They have four co-authors. I offered them suggestions you might find useful:Tip 1: Use question-driven writing
When you think about the questions you want to answer, you have several approaches to whatever you write. An experience report has this structure: what the initial state was and the pain there; what you did (the story of your work, the experience); and the end state, where you are now. You can play with that a little, but the whole point of an experience report is to document your experience. It is a story.
If you are not writing an experience report, organize your writing into the beginning, middle, end. If it’s a tips piece, each tip has a beginning, middle, end. It depends on how long the piece is.
When you use question-driven writing, you ask yourself, “What do people need to know in this section?” If you have a section about the software interacting with the hardware, you can ask the “What do people need to know” and “How can I show the interactions with bogging down in too much detail” questions. You might have other questions. I find those two questions useful.Tip 2: Pair-write
I do this in several ways with my coauthors. We often discuss for a few minutes what we want to say in the article. If you have a longer article, maybe you discuss what you want to discuss in this section.
One person takes the keyboard (the driver). The other person watches the words form on the page (the navigator). When I pair-write with google docs, I offer to fix the spelling of the other person.
I don’t know about you, but my spelling does not work when I know someone is watching my words. It just doesn’t. When I pair, I don’t want the writer to back up. I don’t want to back the cursor up and I don’t want the other person to back up. I want to go. Zoom, zoom, zoom. That means I offer to fix the spelling, so the other person does not have to.
This doesn’t work all the time. I’m okay with the other person declining my offer, as long as they don’t go backwards. I become an evil witch when I have to watch someone use the delete/backspace key. Witch!Tip 3: Consider mobbing/swarming on the work
If you write with up to four people (I have not written with more than four people), you might consider mobbing. One person has the keyboard, the other three make suggestions. I have done this just a few times and the mobbing made me crazy. We did not have good acceptance criteria, so each person had their own idea of what to do. Not a recipe for success. (That’s why I like question-driven writing.)
On the other hand, I have found that when we make a list of sections—maybe not a total outline—pairs of people can work on their writing at the same time. Each pair takes a section, works on that, and returns to the team with the section ready for review. I have also been in a position where someone did some research and returned to the writing team.
I have also been in a position where someone did some research and returned to the writing team.Tip 4: Use a Short Timebox for Writing
When I pair, I write or navigate in no more than 15-minute timeboxes. You might like an even shorter timebox. With most of my coauthors, I don’t turn on a timer. I write for one-to-several paragraphs and then we switch. We have a little discussion and then we’re writing again. Most of my timeboxes are 5-7 minutes and then we switch.Pair Writing Traps
I have seen these traps when pair-writing:
- One person dictates to the other person. That smacks of first-author, all-the-rest-of-you-are-peons approach.
- One or both of you talk without writing. No. If someone isn’t writing in the first 90 seconds, you’re talking, not writing. Write. (This is the same problem as discussing the design without writing code to check your assumptions about the design.)
I didn’t realize I would make this a series. The post about writing by yourself is Four Tips to Writing Better and Faster.
I have a special registration for my writing workshop for pairs. If you are part of a pair, take a look and see if this would work for you.
“Education is a progressive discovery of our own ignorance.”
Will Durant (1885 – 1981)
I’ve thought about getting an MBA from time to time throughout my professional career. It was always a hard thing for me to justify for a few reasons. First, an MBA is very expensive and you never know if you will get that money back in terms of earnings afterward. The graduate schools certainly want you to think so, but when I look around, there are a disturbing number of MBA’s that aren’t working in management. It seems P.T. Barnum may have been right, there’s one born every minute. Second, getting another degree, MBA or not, requires an enormous expenditure of energy. This is energy that I could be applying to improving my existing career, or perhaps starting my own business, or drinking beer – I just can’t decide. Why go to school to burn energy that might be better spent elsewhere? Finally, an MBA is boring. I mean really boring. I’ve seen the curriculum and thought to myself, “Why would I do that to myself?” Honestly, I’m really not a very good student. I know myself well enough to recognize that if I’m not terribly passionate about something, odds are that I will get bored and then perform poorly. When I look at the average business school curriculum, it’s really hard to give a damn.So getting an MBA has been something I’ve personally found hard to approach.
Of course, these reasons are easily and reasonably countered. I certainly don’t discount that there is value in an MBA, but the question is, “is there value for me?” Everyone has to answer that question for themselves. I can afford the expense, so while the costs are daunting, they aren’t prohibitive. And as far as energy expenditure is concerned, that probably isn’t a problem either. If you can build a boat, you can probably manage an MBA. But what about the boring curriculum? What can I do about that? With existing programs, probably not much. But what if I could make my own curriculum? What if I could customize an MBA to focus on areas that I’m really passionate about? What about an Agile MBA?
It’s probably a silly idea. I’m quite sure that it’s not an original idea either, but I’ve yet to find anything like it. I’ve found this: https://leanmba.wordpress.com and it’s certainly a lot of what I was thinking about (it’s really good), but I think there is more to an MBA. It makes me wonder, what would an Agile MBA be like? What would the curriculum be like? What would the classroom interactions be like? What would the overall experience be like? How could we build this program?
These are all good questions. Let’s start with the curriculum. Let’s take a peek at a few traditional MBA curriculum’s and see what we need to cover (from an agile perspective):
3. Statistics/Data Analysis
4. Technology & Operations Management
7. Problem Solving
…or something like that. That’s what I came up with after a brief survey of a few MBA programs. They all look pretty much the same. Yawn.
So I guess this is a starting point. Looking at the list above, I have to wonder, what would an Agile version of this curriculum look like? What books would I recommend? What courses, classes, or certifications would I require? Looking at this list, I think I just might be able to do that. We’ll take these one at a time over the next few weeks.
Filed under: Uncategorized
Ahoy there! With the arrival of 2016, all our releases will now start with the number 16 (oh and happy new year). We have a minor release update for you; here are some of the changes you will notice:
- Global holiday settings for Release Planner
- Item chart drill down
- UI improvements
- And more! Check out our full 16.0 version release notes
Global holidays are now available in the Release Planner. To set a holiday for sprint or release, select your iteration inside the planner and then navigate to the calendar icon to black out global vacation days for all users.Get any holidays scheduled within your release
This will remove these days from your user capacity calculations so you get a much more accurate picture with little effort.Item chart drill down
Do you like to drill down for more information? Well, the item chart has been updated to provide more information for an additional series. For example, you can first see how many items are sitting in each workflow step and then you can click on any given workflow step to see who is assigned those items.You can dive deeper into your item charts by clicking on a section.
To set this up, just edit your item chart and select any series you wish to apply. You will find aggregation types like “sum” and “average” will include a “rate” field.The Rate field will appear if you select “Sum” or “Average” under aggregation type
This is a multiplier, and it may come in handy if you wish to apply it as a flat bill rate for a bar chart display.UI improvements
In our efforts to continue streamlining your user experience, we have added additional improvements like:
- Set project default field templates when adding items with All Projects folder selected
- Keep ongoing required fields data when switching from quick add to edit full add
- When creating an item from a Zendesk ticket, release selection is now available
Lastly, we made numerous changes to the tutorial for your new users. For more information on all our releases, be sure to check out our version history. Otherwise, we will see you in the next release!