As I write the program management book, I am struck by how difficult it is to estimate large chunks of work.
What can you do? Here are some options:
- Plan to replan. Decide how much to invest in the project or program for now. See (as in demo) the project/program progress. Decide how much longer you want to invest in the project or program.
- Work to a target date. A target date works best if you work iteratively and incrementally. If you have internal releases often, you can see project/program progress and replan. (If you use a waterfall approach, you are not likely to meet the target with all the features you want and defects you don’t want. If you work iteratively and incrementally, you refine the plan as you approach the target. Notice I said refine the plan, not the estimate.
- Provide a 3-point estimate: possible, likely, and worst case. This is PERT estimation.
- Provide a percentage confidence with your estimate. You think you can release near a certain date. What is your percentage confidence in that date? This works best with replanning, so you can update your percentage confidence.
Each of these shows your estimation audience you have uncertainty. The larger the project or program, the more you want to show uncertainty.
If you are agile, you may not need to estimate at all. I have managed many projects and programs over the years. No one asked me for a cost or schedule estimate. I received targets. Sometimes, those targets were so optimistic, I had to do a gross estimate to explain why we could not meet that date.
However, I am not convinced anything more than a gross estimate is useful. I am convinced an agile roadmap, building incrementally, seeing progress, and deciding what to do next are good ideas.
With internal releases, everyone can see the project or program progress.
In addition, we have a quarterly external release. Now, your project or program might not be able to release to your customers every quarter. But, that should be a business decision, not a decision you make because you can’t release. If you are not agile, you might not be able to meet a quarterly release. But, I’m assuming you are agile.
You might need to replace MVPs with MIFS, Minimum Indispensable Feature Sets, especially at the beginning.
If you always make stories so small that you can count them, instead of estimate them, you will be close. You won’t spend time estimating instead of developing product, especially at the beginning.
You know the least about the risks and gotchas at the beginning of a project or program. You might not even know much about your MIFS or MVPs. However, if you can release something for customer consumption, you can get the feedback you need.
Feedback is what will tell you:
- Are these stories too big to count? If so, any estimate you create will be wrong.
- Are we delivering useful work? If so, the organization will continue to invest.
- Are we working on the most valuable work, right now? What is valuable will change during the project/program. Sometimes, you realize this feature (set) is less useful than another. Sometimes you realize you’re done.
- Are we ready to stop? If we met the release criteria early, that’s great. If we are not ready to release, what more do we have to do?
Here’s my experience with estimation. If you provide an estimate, managers won’t believe you. They pressure you to “do more with less,” or some such nonsense. They say things such as, “If we cut out testing, you can go faster, right?” (The answer to that question is, “NO. The less technical debt we have or create, the faster we can go.”)
However, you do need the planning of roadmaps and backlogs. If you don’t have a roadmap that shows people something like what they can expect when, they think you’re faking. You need to replan the roadmap, because what the teams deliver won’t be everything the product owner wanted. That’s okay. Getting feedback about what the teams can do early is great.
There are two questions you want to ask people who ask for estimates:
- How much would you like to invest in this project/program before we stop?
- How valuable is this project/program to you?
If you work on the most valuable project/program, why are you estimating it? You need to understand how much the organization wants to invest before you stop. If you’re not working on the most valuable project/program, you still want to know how much the organization wants to invest. Or, you need a target date. With a target date, you can release parts iteratively and incrementally until you meet the target.
This is risk management for estimation and replanning. Yes, I am a fan of #noestimates, because the smaller we make the chunks, the easier it is to see what to plan and replan.
We need planning and replanning. I am not convinced we need detailed estimation if we use iterative and incremental approaches.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
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.
Suppose your boss has not bought into trying an agile approach in your organization. You schedule a meeting with the boss, and stress how your organization should use Scrum because Scrum:
- Has short time boxes
- Relies on self-organization
- Includes three distinct roles
And based on this discussion, your boss isn’t interested.
Why? Because you focused on the features of Scrum rather than its benefits.
Product owners and Scrum teams make the same mistake when working with the product backlog. A feature is something that is in a product—a spell-checker is in a word processor. A benefit is something a user gets from of a product. By using a word processor, the user gets documents free from spelling errors. The spell-checker is the feature, mistake-free documents is the benefit.
It is generally considered a good practice for the items at the top of a product backlog to be small. Each must be small enough to fit into a sprint, and most teams will do at least a handful each sprint.
The risk here is that small items are much more likely to be features than benefits. When a Scrum team (and specifically its product owner) becomes overly focused on features, it is possible to lose sight of the benefits.
Scrum teams commonly mitigate this risk in two common ways. First, they leave stories as epics until they move toward the top of the product. Second, they include a so-that clause in their user stories. These help, but do not fully eliminate the risk.
Let’s return to your attempt to convince your boss to let your team use Scrum. Imagine you had focused on the benefits of Scrum rather than its features. You told your boss how using Scrum would lead to more successful products, more productive teams, higher quality software, more satisfied stakeholders, happier teams, and so on.
Can you see how that conversation would have gone differently than one focused on short time boxes, self-organization and roles?
You may be considering attending the upcoming Scrum Coaching Retreat (SCR) to be held in Franschhoek, near Cape Town on 09-11 February 2015. And you may be wondering what the value will be to you. You may also need to find a convincing argument for your boss to sign off on the registration fee and, perhaps, travel costs from Jhb or elsewhere.
Well in this month’s blog post, Peter Hundermark shares his personal experiences of past Scrum Coaching Retreats in Colorado and London. Discover what he learnt and what to expect from South Africa’s inaugural event! Read more HERE.
Certified Scrum Master (JHB)
03-04 Feb 2015
FNB Conference & Learning Centre, Sandton
Certified Scrum Product Owner (CPT)
23-24 Feb 2015
Steenberg Hotel, Cape Town
Certified Scrum Master (JHB)
10-11 Mar 2015
FNB Conference & Learning Centre, Sandton
Course schedule and Book Online
The post News update 2015/01 – Scrum Coaching Retreat Cape Town appeared first on ScrumSense.
Happy 2015 Axosoft users! We’re greeting the year with a smaller release as we prepare for a few ambitious releases later this year. Here’s what’s new in Version 14.6:
- Centralized Pick Lists and List Types
- Updated importing
- Daily Scrum update
Of course, we squashed some bugs along the way. Check out our Version History page for a list of bug fixes in this release.
Let’s elaborate on feature updates! First, you’ll notice we’ve centralized all pick lists and list types when you go to Tools / Fields / List Types. Pick lists and list types such as status, billing type, and time units can all be modified in one place.
So if for example you need to change the default status options, select ‘status’ and customize the list to match your preferred statuses.
Next, we’ve updated the importing UI. Things are cleaner, simpler, and familiar to anyone who imports often. Like before, you are able to save import templates so Axosoft remembers how you like to map your .csv spreadsheets columns to new item fields.
Lastly, we have included a Teams dropdown menu in the Daily Scrum. Use this to focus on your specific team’s list of items for any given release.
Short and scrumptious, yes? Expect numerous more updates throughout the year. And if you like these updates in video format, please subscribe to our lovely Youtube channel.
Football players spend a lot of time studying their Playbooks. And Coaches spend a lot of time creating and updating them. These guys are serious. The stakes are high in the NFL; millions of people are watching. Their stated goal is the same each week; to win. That means they gotta work really well together and know what they’re doing.
I think the game of American football is a great example to follow as an Agile team in the corporate world. We all need some help with remembering stuff, and getting it down so we can execute on game day. Even if we’ve done it many times before, it’s easy to get forget; there’s just so much to know and remember. This is hard stuff we’re doing, and it’s in constant flux. We often find ourselves wanting someplace to go for reference, clarification, advice, dare I say… ‘best practices.’
I’ve had several clients (both large and small) ask me for something they could use to document the way they ‘do Agile.’ If they’re new to the game, often they will look to a consultant or Agile Coach to guide them or help create this information.
Enter ‘The Agile Playbook.’
So what is an ‘Agile Playbook,’ anyway?
In short, it’s a helpful guide. It can come in many forms. For now, let’s stick with the football analogy. If you’ve watched an NFL game recently, you’ve probably seen the coach holding up a play sheet, as he decides what play to call. If you (or your kid) has an XBOX or PlayStation with Madden NFL, you know it has a Playbook feature built into it. Note: this could be an interesting feature opportunity for Agile Lifecycle Management (ALM) tool providers, huh? But I digress. So, as for the Playbook itself, I think of this as the larger, over-arching deliverable.
Transferring this idea of an NFL Playbook into the world of Agile software development is natural. I’ve heard it referred to by different folks in similar ways, like ‘Agile one-stop shopping’, or an ‘Agile Coach in a Box’, or ‘How we do Agile here at Company XYZ’. I personally like the term ‘Agile Playbook’ because it’s short, simple, descriptive, and I believe it drives home the team concept nicely.
Who wants an Agile Playbook?
Can you imagine an NFL team without an organized list of plays? So why would we think it’d be any different in our Agile organizations? I remember playing pickup football and we’d draw pictures in the dirt of what we wanted to do. That was fine for a pickup game, but even my nine-year-old son’s flag football team has a playbook. So the question of ‘Who wants it?’ is an appropriate one. If we think of Mike Cohn’s user story template (As a ___, I want to ___, so I can ___), this is the ‘As a’ piece. Who are we doing this for, anyway? Is it the PMO Director? The ScrumMasters? Product Owners? The Team? Program and Portfolio Management? Executives? The answer, in my six years of personal Agile consulting experience, is ‘all the above.’ If they don’t ask about this at some point, it’s usually because they haven’t thought about it yet.
Why do they want an Agile Playbook?
Hopefully, because it adds value. This is the ‘So I can’ part of the story. It’s a guide to help them get where they want to go. It’s something we can point to when someone asks, “How are we doing Agile in our organization?” It’s something we can go to for reference when nobody else is around. It can even be used as an onboarding tool.
The Agile Playbook also gets us thinking not only about how we work, but how we can improve our processes. Are we really being empirical? Give it a little love in your retrospectives. Perhaps there’s an opportunity to update the Playbook. Oh, and if by chance you don’t see any value in it, simply don’t do it.
Yes, it’s a document.
OK, I know what many of you must be thinking by now… The Agile Manifesto says ‘Working software over comprehensive documentation.’ Yes, an Agile Playbook is a document. And yes, it’s likely to be pretty comprehensive. But that’s a relative term; more specifics on this will follow in a bit. The Agile Manifesto doesn’t say documents are evil. In this case, I believe it’s a very helpful and necessary document to have available in order to get everyone on the same page, and to show auditors that our processes are documented (they like that kinda stuff, ya know). An Agile Playbook is a big deliverable. It takes a lot of time, effort and know-how to put something like this together.
When I did one for a client a couple years ago, we employed a full-time Tech Writer for about a month. That was a huge help. I had initially tried to do it on my own, in my spare time, but that didn’t work out too well. The folks in the Agile PMO, including myself, provided the content, primarily.
But I’ve seen other organizations go with almost nothing documented, just pulling in a coach or two and letting it roll. Maybe sharing a few slide decks on an internal page. No strong desire to document the why, when and how we do stuff. I wonder if that’s because they hadn’t thought about it, didn’t want it by design, or just didn’t have the bandwidth. Or maybe there were other reasons. Personally, I believe that not documenting something this important to the agile transformation of your organization is irresponsible.
And having it documented – but all over the place in different formats – can be chaotic. I don’t like to make people go hunt down stuff, let alone guess or assume anything.
My opinion is that this should be as close to one document (or series of web pages) as possible, not multiples; i.e., not nine Powerpoint slide decks, seven Excel spreadsheets, and 12 Word documents with a bunch of buried links to even more documents, slide decks and spreadsheets. Make it as simple as possible. It’s one place to go. One thing to print off (if you desire to have a hard copy) and carry with you for reference. One URL to save as a favorite.
It can help us realize gaps in the way we work.
What I learned early on is that the hard work of creating an Agile Playbook forces us to give a long, hard look at the way we’re working now, and how we want to work in the future. It’s cathartic. It helps us identify areas where we can improve our processes. It forces us to ask some difficult questions. And make some difficult decisions.
One way in which to identify areas of improvement around your process is to identify your value streams. This is a basic Lean principle. I’m sure we’ve all done something like this. How efficient are we in going from start to finish (request to deployment, concept to cash)? Our goal should be to optimize this. Look to reduce delays, inefficiencies, and improve our cycle time.
How do we document tools and technical practices?
Let’s not forget how our tools and technical practices play into this, as they’re an important factor in how we get work done. If your organization is using an Agile Lifecycle Management tool, the Agile Playbook might include best practices on how to use that as well – either melded throughout, or as a separate section.
Same goes for development tools that help us with…
– Continuous integration – Jenkins, Hudson
– Defect Management – Bugzilla, JIRA, HP Quality Center
– Integrated Development Environment – Eclipse, Visual Studio
– Test Management – HP Quality Center
– Source Code Management – Git, Subversion
– Agile Portfolio and Project Management – VersionOne, et al.
This can be a lot of information, so when documenting for the Agile Playbook, this is an area where I make heavy use of links to information beyond the basics of each of the tools we use.
It should be comprehensive, yet brief.
If you can’t fit the Agile Playbook into your front pocket comfortably, it’s probably too big. When I say brief, I mean about under 50 pages for a large organization. Any more than that, I think folks begin to feel overwhelmed and push it away. Any less, and it’s hard to be comprehensive. There’s no science behind that decision, but if I apply my own average attention span to the matter, this sounds about right. I think much of this also depends on the format you use: Microsoft Word, Powerpoint, HTML, etc. Again, where appropriate, I like to make liberal use of links to other documents/sources to help minimize the length. I recommend placing it on a well-known organizational site such as Wiki, Sharepoint, etc. Provide a highly visible and pronounced link from your internal company home page, and give the option of printing out a hard copy. In fact, I like to have several hard copies available in the Agile PMO to hand out to folks who want one. You’d be surprised how quickly they go. I’ve found that a nice ringed binder works best. That way, if there are changes, you can swap out a page or two. That said…
Did you know…
Most NFL teams now use tablets (iPad or Surface) almost exclusively for their Team Playbooks?
If you’ve watched ‘Hard Knocks’ on HBO, you already know that the phrase “Turn in Your iPads” has started replacing “Turn in Your Playbooks” when players are cut from an NFL team. Those teams have discovered that the technology goes far beyond the old playbook capabilities. There’s a product called ‘PlayerLync,’ which is at the forefront of this movement. It has revolutionized the way teams push out film and significantly altered the way they communicate. Beyond saving printing costs, digital playbooks are improving the effective, real-time communication by allowing coaches and quarterbacks to add and share plays with the click of a button. Every time new data, film or information is added, a banner alert pops up (like a text message), signaling players to view the updates.
Oh, and PlayerLync isn’t just for professional sports teams. Here’s a short clip on how Chipotle and others are using it to push content to their teams:
Uniqueness and commonalities
I’ve helped put together a number of these Agile Playbooks for different clients now, and each was both unique. But there are many commonalities, like the general Agile principles and practices. At the end of the day, folks want to know what to do, who does it, when to do it, and why. All these things can be exclusive to the organization or industry. The extent to which Scrum, Lean, and XP practices are applied also varies from company to company.
The fear seems to be centered around teams in an organization that are using both the framework and the tools differently. It could be that we’re not all using the Agile Lifecycle Management tool in the same way. How in the world can we expect to have rolled up views into the different management levels (Portfolio, Program, and Project) without a common agile project management tool? This opens the door to confusion on many levels, especially when we start talking about agile metrics/reports. But it’s not just the management level that has a problem if we’re not all on the same page. The individual team members also experience fear… fear of doing the wrong thing, or doing it incorrectly, getting called to the carpet or, worse yet, being publicly shamed, written up, or fired. The idea is that if we’re all on the same page, and everyone knows what’s expected, this fear diminishes greatly. Life gets better for everyone.
Start with an outline…
Finally, you were probably wondering when I was going to get here. By the way, each organization’s Agile Playbook is their own. I cannot share the exact Playbooks that I’ve put together with clients, as that information is proprietary. But I can share with you a more generic outline of what an Agile Playbook might look like:
About the Agile Playbook
What is Agile and Scrum?
Implementing Agile and Scrum at Company XYZ
Essentials of Agile and Scrum at Company XYZ (How ‘We’ Do It)
Agile Reporting/Agile Metrics
Staying Compliant with Agile
Company XYZ Communities of Practice (COP)
Do you have a Playbook for how you ‘do Agile’ in your organization? If so, what does it look like? If not, why?
I published a new Pragmatic Manager this past weekend. It’s called Discovering Your Leadership.
It has a pointer to the Influential Agile Leader event that Gil Broza and I are leading in San Francisco and then in London. You can still get early bird pricing, until Feb 15. Don’t miss this opportunity—we’re only leading it twice this year.
At Rally, we love our Apple laptops. Typically we use them day in and day out for three years or more, after which they enjoy their next phase of life.
In 2014, we started a donation program to place them into good use at “retirement homes”—organizations that would appreciate them until their useful life is over. Through the course of last year, we donated 95 MacBooks valued at nearly $30,000 to Colorado nonprofits and educational institutions. I’m happy to share a few of their stories.Boulder Emergency Squad
At Rally, Cliff Rosell is a Senior Financial Analyst; but at Boulder Emergency Squad (BES) he’s a professional rescuer, IT supervisor, Resource Planning Supervisor, and Board Member —roles that add up to about 1,000 annual volunteer hours.
In 2014, Rally donated two iMacs and three MacBook Pros to support the work of this life-saving community organization. According to Cliff, “Prior to Rally’s donation, we had one desktop computer. Now we’ve upgraded our radio dispatch computer, have a dedicated system for training presentations, enabled two officers to work remotely, and have added a dedicated laptop for any member to use. Rally’s donation has really helped modernize BES in a way that could not have been done otherwise.”
Boulder Emergency Squad volunteer Nicolas Venot looks at map and call data on the donated computer used for radio dispatch at the organization’s headquartersBrighton High School
Rally IT Director Jesse Brouillette spends his 1% paid volunteer time helping out at Brighton High School (BHS), where he uses his technology skills and expertise to help the small IT staff. The school has two computer labs but that need to serve nearly 2,000 students, so access to technology is limited.
Jesse and his wife, Emerald—who is Dean of Students at BHS—brainstormed affordable and feasible ways to increase technology access at the school, and decided to build a self-contained mobile lab that could be wheeled into classrooms. Rally donated 42 retired laptops for the project, and this mobile cart how now effectively doubled the computers available for student use.
Jesse Brouillette (right), Rally’s IT Director, volunteers at Brighton High School’s IT department and helped create a mobile lab with Rally-donated laptops.
In recognition of the contribution, Rally was honored with the school district’s “Reaching In” award, given to a business or other organization from the community that makes a significant impact.Open Media Foundation
The Open Media Foundation (OMF) is an innovative media and technology nonprofit dedicated to putting the power of the media in the hands of the people, enabling everyone to engage in their community and bring about the change they wish to see in the world. OMF accomplishes its mission by providing access to affordable, high-end media and technology services. The staff and volunteers offer training and tools that enable everyone to represent their own voice in the media conversation.
With 10 laptops Rally donated in September, OMF was able to begin offering members of Denver Open Media (DOM) the ability to work on projects remotely. Explains Liz Wuster, Member and Donor Relations Manager, “In fewer than 60 days, the laptops have been checked out 34 times, for a total of 2,591 hours! They have been used individually by our members, and in bulk by organizations, such as the Denver Film Society, in its efforts to teach editing and animation to youths. We offers classes around tech capacity and editing, which give our members a better grasp of how to most effectively use these laptops.”
“The MacBooks donated by Rally have been very useful in terms of doing edit jobs on Adobe Premiere and making graphics on Adobe Photoshop. They've allowed me to get things done in the video production department when I can't come in to Denver Open Media during office hours.” - Brian Nemeth, a DOM memberI Have a Dream Foundation of Boulder County
ln October, the I Have a Dream Foundation of Boulder County (IHAD) put 10 Rally-donated MacBook Pros to immediate good use. Each year, the organization selects a cohort of 50-60 low-income “Dreamers,” at-risk kids who are partnered with community members. These Dreamers are encouraged in elementary school to believe that college is an attainable goal, and as they grow up they receive extensive career and college preparation guidance, sponsored campus visits, and assistance with the application process.
The Dreamer students are using the laptops to complete coursework, projects, and internships as they prepare to enter college. IHAD staff members use the laptops to raise needed funds for programs through grant writing, as well as to recruit, interview, and train tutors and mentors. IHAD’s program director will use her laptop to manage the caseload for 60 new Dreamers—tracking attendance, grades, and case notes as they begin their journey toward high school graduation.
“Before this MacBook, I didn't have access to a laptop in order to conduct off-site volunteer recruitment presentations, interviews, and trainings. I am very grateful for the new laptop from Rally!” commented Ashley, Volunteer Director at I Have a Dream Foundation
We’re delighted to hear the stories of how our “old” laptops are helping others in their next stage of life. We now have more requests than we can fulfill, so 2015 is likely to be another busy year for Rally laptops to find new, happy homes.Geri Mitchell-Brown
Value is a funny thing. In enterprise agile coaching, I’m frequently encountering teams that are trying to either (1) complete every single project at the same time because they are all equally valuable, or (2) using a nebulous unit of sorts (say a 100 point scale) to indicate how valuable a work item may be.
In the first case, its usually pretty straight forward to identify that all of the projects are not truly equal in importance and we limit the number of work items to the actual capacity of the delivery system.
In the second case, a team has typically taken my advice and is now trying to figure out what work items are really the next most valuable to the business. Frequently these teams will ask for a value scale, one that helps them to figure out if they need to build item ‘A’ or item ‘B’ next. My answer in this case is almost always a question. It goes something like this:
Me: “Which of the two items have a higher cost of delay?”
Team: “I don’t know, I think item ‘B'; but, if we ask person A or B from some other part of the organization they would probably say item ‘A’.”
Me: “Well, do you know the cost of delay for both items, it should be simple math to choose between them if you do”
Team: “No, we have a guess, but we really don’t know”
It is usually around this time that the teams will start asking for a method or system that can be used to help establish value for work. My answer is usually a bit over simplified; but, then again, perhaps it isn’t. My answer is usually ‘currency’. If the business exists to make money, then the value we are placing on work should always tie back to the potential for currency.
If a team is making tradeoffs based on value, I would like to see how that work item will turn into real money for the business.
What are your thoughts? Have you found any other approaches that work equally well?
Acceptance Test-Driven Development and Test-Driven Development - How They Are the Same and How They Are Different Revisited
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
You may be considering attending the upcoming Scrum Coaching Retreat (SCR) to be held in Franschhoek, near Cape Town on 09-11 February 2015. And you may be wondering what the value will be to you. You may also need to find a convincing argument for your boss to sign off on the registration fee and, perhaps, travel costs from Jhb or elsewhere.What is a Scrum Coaching Retreat?
Scrum Coaching Retreats are so-called because the international Scrum Alliance is the title sponsor, which enables the organisers to offer astonishing value for money to the participants. In practice anyone who finds him- or her-self in a role where they need or want to help other individuals or teams get better is a “coach” and is qualified as a participant! This certainly includes agile team coaches, Scrum Masters, Kanban coaches, project managers, product owners/managers and many more.
SCRs are regional events, organised by local agile coaches who have participated in at least one prior event and have some track record in organising agile events.
I’ve had the privilege of participating in two prior international SCRs (as well as a SUGSA-organised weekend coaching retreat, which was also great).Boulder, Colorado (December 2011)
The inaugural SCR took place in Boulder, Colorado in December 2011. It was freezing cold with lots of snow. Around 75 participants from the US, Canada and even further afield gathered in the historic Boulderado Hotel with the sole aim of going on a learning journey together. Experience levels ranged from Pete Behrens and Roger Brown, who established the Certified Scrum Coach programme in 2007 to Scrum Masters with just a few months of agile experience. Hardly anyone had heard of Kanban back then!
The idea was born of a limited number of people self-organising into teams who would together go on a learning journey around a chosen topic. On the first day topics were generated open-space style and teams formed . On day two each team demonstrated to everyone else in a “joint review” session what they had done for the past day-and-a-half.
Old friendships were rekindled and new ones forged both during the team work and in the various cosy bars and restaurants in Boulder. For example, I remember Sigi Kaltenecker, and I having a fine meal and chat with Lyssa Adkins. Boulder is comparable in some ways with Franschhoek: good food married with grand scenery; just colder!London (June 2014)
Fast forward more than two years to June 2014 and we find ourselves in London during Spring. As an aspirant organiser I was invited to participate. My good friend and former business parter Marius de Beer made the journey across the pond from Vancouver and we had an awesome time together.
Marius and I chose to explore the topic of how to help novice Scrum Masters to become awesome team coaches. We cunningly conspired to recruit some quite inexperienced participants to join our team: we deliberately wanted to have their “beginner’s mind” and understand their specific needs. We chose Geoff Watts, an experienced CSC (and CST) as our team’s product owner and set to work to create our vision, all on the first evening. Over the next two days our team was able to deliver tangible results in the form of a working “Scrum Master Exchange” and a “Mentoring Programme”.
The new and improved structure for the London event included “two sleeps”. This meant a late afternoon start with topic generation, team selection and vision creation on day 1. Day 2 and 3 mornings were both fully devoted to working in these teams. Moreover, teams ran two sprints with a review and retrospective after each, enabling them to inspect and adapt. For some teams this resulted in delivering two shippable product increments. For at least one it meant abandoning their current direction after sprint 1 and reformulating their vision for sprint 2!
The retreat closed with a large joint retrospective: around 75 people participated in the closing circle!Learnings
The day after London closed, Marius and I spent some hours reflecting on the event, capturing what we believed should be carried forward to the Franschhoek event, and what new experiments we would like to run. So you can expect something quite similar to London, yet with some interesting new tweaks!
More SCRs have been held since London in the US and Asia. The “two sleeps, deep dive” structure with a limit of about 75 participants has persisted.Franschhoek Scrum Coaching Retreat
Our theme in Franschhoek is “Small Improvements”. This reflects our strong belief that lasting change happens slowly but surely.
What I can promise is that you and your organisation will be the better for your participation!
At a very pragmatic level for just $600 (under R7000) you will get:
- A pre-retreat workshop of ~4 hours on Monday 09 Feb for participants who feel they are “starting out” as coaches and want a little extra guidance and confidence. This will be facilitated by some of the most experienced local and international agile coaches. Lunch will be provided. Attendance at this workshop is optional, but the full cost and lunch is included in your registration fee.
- The two-and-a-half day main event starting with topic generation and team formation on Monday evening and continuing on Tuesday and Wednesday.
- A new, high-energy, problem-solving coaching clinic on Tuesday afternoon. It will be unlike anything you have seen or done before!
- Two nights accommodation (Monday & Tuesday) at the comfortable (if not luxury—don’t tell your boss!) Le Franschhoek Hotel & Spa.
- All breakfasts and lunches from Monday lunch through to Wednesday.
- Alfresco dinner on Monday (braai) at the hotel for all participants.
- For dinner on Tuesday you are free to grab a few (new) friends and head off to one of the many, great restaurants in Franschhoek, which range from the finest dining in the country to a simple pizzeria.
- The venue is set in the Franschhoek valley and winelands, one of the most awesome regions in our beautiful country. We have great inside and outdoor spaces to choose from, depending on the weather, which is likely to be hot and dry. Bring your bathing costume for use in the pool during down time.
Logistically it will be quite possible for you to fly in from Jhb on Monday morning and return home on Wednesday evening. However, why not spoil your better half with a weekend in Franschhoek before the event. The Le Franschhoek Hotel & Spa, or one of the many other fine establishments in the region, will love to pamper you both!
The following is a guest post from Lisa Crispin. Lisa is the co-author with Janet Gregory of "Agile Testing: A Practical Guide for Testers and Agile Teams" and the newly published "More Agile Testing: Learning Journeys for the Whole Team". I highly recommend both of these books--in fact, I recommend reading everything Lisa and Janet write. In the following post, Lisa argues the benefits of scheduling anything that's important. I am a fanatic for doing this. Over the holiday I put fancy new batteries in my smoke detectors that are supposed to last 10 years. So I put a note in my calendar to replace them in 9 years. But, don't schedule time to read Lisa's guest post--just do it now. --Mike
During the holidays, some old friends came over to our house for lunch. We hadn’t seen each other in a few months, though we live 10 minutes apart. We had so much fun catching up. As they prepared to leave, my friend suggested, “Let’s pick a date to get together again soon. So often, six months go by without our seeing each other.” We got out our calendars, and penciled in a date a few weeks away. The chances are good that we will achieve our goal of meeting up soon.
Scheduling time for important activities is key in my professional life, too. Here’s a recent example. My current team has only three testers, and we all have other duties as well, such as customer support. We have multiple code bases, products and platforms to test, so we’re always juggling priorities.Making time
The product owner for our iOS product wanted us to experiment with automating some regression smoke tests through its UI. Another tester on the team and I decided we’d pair on a spike for this. However, we had so many competing priorities, we kept putting it off. As much as we try avoid multi-tasking, it seems there is always some urgent interruption.
Finally, we created a recurring daily meeting on the calendar, scheduled shortly after lunchtime when few other meetings were going on. As soon as we did that, we started making the time we needed. We might miss a day here or there, but we’re much more disciplined about taking our time for the iOS test automation. As a result, we made steady, if slow, progress, and achieved many of our goals.Scheduling help
Even though both of us were new to iOS, pairing gave us courage, and two heads were better than one. We’d still get stuck, though, and we needed the expertise of programmers and testers with experience automating iOS tests. Simply adding a meeting to the calendar with the right people has gotten us the help we needed. Even busy people can spare 30 minutes or an hour out of their week. Our iOS team is in another city two time zones away. If we put a meeting on the calendar with a Zoom meeting link, we can easily make contact at the appointed time. Screensharing enables us to make progress quickly, so we can stick to short time boxes.
Another way we ensured time on our schedule for the automation work was to add stories for it to our backlog. For example, we had stories for specific scripts, starting with writing an automated test for logging into the iOS app. Once we had some working test scripts, we added infrastructure-type chores, for example, get the tests running from the command line so we can add them to the team’s continuous integration later. These stories make our efforts more visible. As a result, team members anticipate our meeting invitations and think of ideas to overcome challenges with the automation.Time for testing
Putting time on the calendar works when I need to pair with a programmer to understand a story better, or when we need help with exploratory testing for a major new feature. I can always ask for help at the morning standup, but if we don’t set a specific time, it’s easy for everyone to get involved with other priorities and forget.
The calendar is your friend. Once you create a meeting, you might still need to negotiate what time works for everyone involved, but you’ve started the collaboration process. Of course, if it’s easy to simply walk over to someone’s desk to ask a question, or pick up the phone if they’re not co-located, do that. But if your team is like ours, where programmers and other roles pair full time, and there’s always a lot going on, a scheduled meeting helps everyone plan the time for it.
If you have a tough project ahead, find a pair and set up a recurring meeting to work together. If you need one-off help, add a time-boxed meeting for today or tomorrow. If you need the whole team to brainstorm about some testing issues, schedule a meeting for the time of day with the fewest distractions. And if you haven’t seen an old friend in too long, schedule a date for that, too!
I have a new column posted at projectmanagement.com. It’s called Does Agile Apply to Your Project? (You might need a free registration.)