If you missed last month’s webinar on How to Grow High Performance Teams Through Mentorship by Peter Saddington, we have attached the audio and slide deck below. Enjoy!
A few problems came up when recording, but we were able to save the audio.
If you missed last month’s webinar on How to Grow High Performance Teams Through Mentorship by Peter Saddington, we have attached the audio and slide deck below. Enjoy!
A few problems came up when recording, but we were able to save the audio.
It’s here on the Apple Store: The Agile Pocket Guide. It’s right there in the “Learning Business Skills” brick on the main page, in conjunction with the Apple WWDC conference.
It is a two week Apple promotion dropping ebook prices to $9.99 starting 6/4 and running through 6/17.
Would love a tweet about it!:
The Agile Pocket Guide is now only $9.99 in the @iBookstore for the Apple #WWDC2013 – http://ow.ly/lHo6F
There are lots of other books on sale too… here are the other books at the promotion!:
Having been a fan for so long of Jerry Weinberg’s work, I obviously took the opportunity to get something personal from him. His writing has so greatly influenced how I operate as a consultant and if you ever spend more than a couple hours with me, you’ll probably hear me quote him at some level.
Thanks a bunch Jerry. Even though the Law of Raspberry Jam is alive and well… coupled with the Weinbergs’ Law of Twins… sometimes statistical outliers do occur. Count me to be one of them.
Also, thank you Don Gray for being a great colleague, mentor, and friend. Oh, the client’s we’ll encounter together!
These days almost everyone is familiar with the benefits of Agile methodology. Marked by collaboration, self-managing teams and real-time response to customer feedback, Agile has evolved beyond buzzword status to become a pillar of the technology landscape. Its advantages are just as well-known: customer-oriented solutions, accelerated product release and cost savings, just to name a few.
The rewards are so remarkable, in fact, that some innovative companies are using the Agile paradigm to transform their business culture. My own business has done just that, and we are consistently meeting the goals we set out to accomplish. By applying the same Agile methodologies to drive business strategy and execution, many businesses – ours included – have achieved breakthrough results.
A Shift in Culture
So how do Agile businesses differ from traditional corporate cultures? It starts at the top. Many companies govern through a Command and Control management style that cascades instruction down a hierarchy. Communication and feedback are limited and slow-moving; rather than harness the expertise of the organization, the company acts on the judgment of a few, resulting in ineffective decisions.
Agile companies, on the other hand, operate with the flexibility and high performance of Agile development teams. Because operations rely more on collaboration and communication, decisions and solutions are more accurate and effective. Employees are provided with their roles and the tools they need, then empowered to be self-managing.
Agile Business In Practice
You’re probably wondering exactly how Agile culture gets practiced on a day-to-day basis.
Roadmap to Revolution
As you might guess, adopting an Agile business culture can involve a learning curve. I considered it a control+alt+delete to the way we did business and still believe that you can’t dabble in applying Agile to your business strategy – you have to fully commit. The below tips can help you some avoid pitfalls.
Transforming your business with Agile methodologies requires a full commitment. This is a complete system overhaul, and leaders who adopt only half-measures will see inefficiency and poor returns. But a full dive into Agile will bring the enhanced communication, empowered teams and faster execution that Agile is known for – and once you’ve experienced it, you’ll never want to go back.
Cliff Schertz is the founder and CEO of Tiempo Development, which provides cloud-focused companies with a powerful, integrated platform of services that transforms the way their products are developed, deployed and supported. For more than 25 years, Mr. Schertz has been leading and growing successful technology service companies, enabling his customers to achieve superior performance, high customer satisfaction and profitability.
Learn more about how to understand your culture using TeamScience.
Developer depression is one of the most important issues that our community needs to address that no one is talking about.
The problem is often made even worse by the prevalence of remote work in companies that don’t recognize the risk of loneliness. Developers working virtually with their teams experience social isolation resulting from the diminished professional and personal interaction with your colleagues that you get from going into the office. And that literally can kill you.
A review of research published in 1988 found that “social isolation is on a par with high blood pressure, obesity, lack of exercise or smoking as a risk factor for illness and early death” . . .
Even without indulging in unwholesome behaviors, . . . loneliness can impair health by raising levels of stress hormones and increasing inflammation. The damage can be widespread, affecting every bodily system and brain function.
Via the New York Times, Shaking Off Loneliness
Fortunately, even as technology, in enabling virtual work, facilitates an accompanying loneliness, it can just as well help us be less lonely as we work remotely. Here are 3 tools that make remote work less lonely and lead us toward making remote work what it should be: awesome.
Chris Savage, CEO of Wistia, told me that iDoneThis helps his company of 20 feel like it did when it was just 4 people sitting around a table.
That tight feeling of camaraderie comes from a shared knowledge on the team of what everyone is working on, feeding the sense that the team is rowing together in the same direction. And this is essential for distributed teams.
iDoneThis makes syncing up very simple and lightweight. iDoneThis emails everyone on your team every day to ask, “What’d you get done today?” Just reply. The next day, everyone gets an email digest showing the team’s accomplishments from yesterday — which gets everyone on the same page, aligned, and ready to go.
It takes the pain out of a daily standup for remote teams, which is a common source of friction. When people have to wake up at weird times and when Skype drops the call over and over, people get frustrated. iDoneThis provides a remedy because it works asynchronously over email.
For entrepreneurs, like Laura Roeder, who’ve built million-dollar businesses with happy and healthy remote teams, iDoneThis is an essential tool “to create a cohesive team where work is recognized and valued,” which is vital to combating the sense of isolation and being out of the loop that so often accompanies remote work.
There’s no substitute for face-to-face conversation when it comes to fighting loneliness. In fact, psychologist Frieda Fromm-Reichmann defines loneliness as “the want of intimacy,” and talking with another person in real-time and seeing their face conveys a far greater sense of intimacy than text on a screen.
Sqwiggle is a video chat app that gives you the immediacy of being in the same office and the intimacy of face-to-face conversation while you’re working remotely. This is a browser-based video chat app that you leave on while you work. Unlike Skype and Google Hangout, you don’t have to initiate a call to talk, and unlike text-based chat, you can actually see the faces of your teammates.
Everyone on your team keeps Sqwiggle running in the background all day while you’re working. To speak with someone, all you have to do is click on their face in the browser. Instant connection with no dialing or inviting, and you can simply start talking.
You can use chat room services like Campfire or Hipchat with your team to maintain some degree of social sanity — but for actually, you know, seeing your team, and looking at their lovely faces, and talking like humans should, nothing really fits the bill.
Via TechCrunch, Sqwiggle Makes Working Remotely Less Lonely, More Awesome
Turntable isn’t a productivity tool at all. It’s actually liable to make your team less productive in the short term — but over time, I’ve seen firsthand how it helps people working remotely feel connected through music, which is a boost for long-term productivity.
On Turntable, each person gets their own cartoon avatar. When you join the same room, which is like a virtual nightclub, you all hear the same music chosen by the room’s DJs. Anyone can be a DJ, and the DJs take turns playing music from their own personal collection or from the service’s wide song selection. If you’re enjoying a song, just click a button — your head will start bopping and the DJ will receive a point. There’s a chat feature to talk about which songs are your favorites.
It’s surprisingly fun and provides a way to express yourself through music. Exploring and discussing your colleagues’ music tastes is a great way to get the sense that you’re hanging out together. One of the biggest casualties of remote work is not only professional interaction around work itself but the missed opportunities to grab a beer after hours and chat on a social level.
Getting to know your colleagues as individual human beings is one of the most powerful sources of connectedness, a key to happiness with work. Feeling like you’re on the same boat, visually interacting with each other, and having a bit of fun all add to that all-important human connection.
“I am a developer, and I have Type II BiPolar and ADHD. It’s not something we talk about, but BiPolar, depression, and ADHD runs rampant in the developer community – they tend to correlate with higher intelligence. Many of the symptoms of this conditions make for great developers, but also cause incredible damage. We recently lost one of our co-workers because of untreated mental illness. I want to share my story – and let people know that it’s okay to talk about these things, that it’s nothing to be ashamed of, and how to get help, and how to help those around them.” – Greg Baugues
If you have 20 minutes, it’s worth listening to. As a developer I fully understand this. I remember the brilliance of some of my peers… and before my studies in the social sciences, I do remember once or twice wondering whether they were brilliant not just because they were awesome, but in addition, they might have a mental condition…
It does make you wonder… or at least it makes me wonder even more… whether our (often) terrible environment of busy-work and the insanity of hustle bustle at work heightens the mental condition… in other words, makes it worse.
Are we killing our brightest knowledge workers?
I know there are more than a few Agilists who are bloggers among us and even more than enjoy taking pictures of their families, friends, their work, and maybe even their food on occasion (admit it, you do it).
[The following is from: https://www.gov.uk/service-manual/agile/what-agile-looks-like.html – What is so amazing is that this is a government website… yes. A GOVERNMENT website. I copied it here because I was so stunned… this is great stuff. Almost like Barack Obama telling us to do Agile]
Agile is a liberating way of working. It does not preclude the use of existing skills and knowledge. But it does require teams, users and stakeholders to adopt new ways of working together.
This short guide lists a few of the behaviours common to agile projects that support successful delivery and learning.
Prioritise features for them over everyone else – including your big, scary stakeholders, and seek their feedback early and often. Really listen to them. Even when they tell you things you don’t want to hear or disagree with. If possible, use data from real people using your product to influence the direction of the project. Your focus on the user should be relentless.
Iterate often. Build something focused on the next most valuable user need and show it to them; listen to their feedback and improve it. Keep doing this until you have something so useful that they would not be without it.
It perhaps sounds like over-simplifying the complexity of software development and project management, but at its heart this is what agile development is all about: “What do you want next Friday?”
The process of delivering incremental, production-ready software allows a team to deliver value to their users and stakeholders regularly. It shortens the feedback loops that might otherwise have been longer using a waterfall methodology. An iterative delivery cycle also forces the team to think about what the most important features are to deliver next and focuses the mind on useable software.
At the end of each delivery cycle, or sprint, teams should run aretrospective to review ‘what worked, what could be improved’ in the next sprint.
The software and the team continue to learn through delivery and iterate and improve throughout the project.
Small teams of between five to ten people are often more productive and predictable than larger teams. Forget man-days and think about the team as the unit of delivery.
A good team includes members with all of the skills necessary to successfully deliver software. A fully-functioning team has three key roles embedded into them, usually full-time:
Product Manager – responsible for delivering return on investment, usually by creating products that users love. The team delivers the Product Manager’s vision.
Delivery Manager (a.k.a. Scrum master or Project Manager) – is the agile expert that is responsible for removing blockers (things slowing a team down). They also usually act as a facilitator at team get togethers.
Team member – Self organising, multi-disciplinary team that delivers prioritised user stories. Responsible for estimation.
You help each other and work together toward delivering your sprint goals. It’s common to encourage team members to pair. It sounds counter-intuitive to have two people work on one thing, but this is not so. Working together closely produces better software solutions, promotes better quality controls and spreads knowledge across the team.
A good team can estimate their output, or velocity, very effectively and consistently. This allows for much more accurate planning.
Releasing little pieces of code often improves quality and visibility and reduces cost to market, but using agile techniques does not guarantee success. You can still fail! What agile methodologies do allow you to do is to spot problems earlier and resolve them.
Here’s a few examples of how:
- releasing working software to your users often allows you to get feedback quickly and hear or see what they think. If the product is wrong you can easily change direction and iterate.
- if your software is rarely released to production you are not demonstrating value to your sponsor. You run the risk of creating a “too-big-to-fail” service that isn’t fit for public consumption but must be released anyway. That means another press headline! Ship! Ship! Ship!
- if your teams’ velocity is consistently volatile, beyond the initial 4-6 sprints, then this is indicative of something that needs fixing. Perhaps there is hidden complexity or poor estimation.
- Test Driven Development (writing tests in code before you develop the features) has a wealth of metrics that highlight quality issues early. Establish what these are early on, baseline and monitor throughout the project.
Don’t be afraid to fail or experiment. Learn to fail, and create a culture that learns from failure.
It’s a myth that you don’t plan on agile projects. The freedom of agile projects does not come free: you have to plan. You just plan differently and continuously.
Agile planning is based as much as possible on solid, historical data, not speculation. The plan must continuously demonstrate its accuracy: nobody on an agile project will take it for granted that the plan is workable.
Typically teams plan together, usually on at least two levels:
- at the release level, they identify and prioritise the features we must have, and would like to have by the deadline.
- at the iteration level, they plan for the next features to implement, in priority order. If features are too large to be estimated or delivered within a single iteration, they break them down further.
These plans are usually reviewed after every sprint and adjusted based on “the weather yesterday”, new facts and requirements that will inevitably be uncovered along the way.
Teams new to agile should be wary of these familiar situations and reactions to doing things differently. They have a bad smell about them and undermine your project and its chances of success.
- Your team is not full time. If your core team of product manager, scrum master, and key members of your multi-disciplinary team are not on the project full-time and spread over many projects then expect difficulties. The team is the unit of delivery and you need focus. Push back on managers and stakeholders if this is happening.
- You don’t have a dedicated team area. Your team should be sat together, preferably in your own room, with space on the walls to draw ideas and stick up cards and post-its. As the project gets going, consciously ‘hack the environment’ to create a working environment conducive to team working. You might upset a few people and challenge some long-standing working practices. But this is so, so important, and really should not be a big ask.
- There’s no continuous integration environment. Start right: with a continuous development environment. If your teams are not insisting on this from the outset then you’ve probably got the wrong team. So much about iterative software development is contingent on the ability to continuously deploy and run automated tests as you do.
- You have a separate QA department. If your team’s attitude to quality is to throw the software they’ve developed over the wall to a QA department, then they’ve not got the right attitude to delivering production-ready software. You need to embed a quality culture into the team.
This is by no means an exhaustive list, but these are most common things to watch out for.
Time to jump on it. Find the results here.
Some facts from the 2012 State of Agile Survey include:
The seventh annual “State of Agile” survey was conducted between August 9, 2012 and November 1, 2012 and collected responses from 4,048 agile practitioners. Sponsored by VersionOne, respondents were recruited from dozens of software development industry channels. The data was then analyzed and prepared into a summary report by Analysis.Net Research.
In Atlanta, GA news:
Action & influence, Inc. announced today that they are hosting more Certified ScrumMaster (CSM) and Certified Product Owner (CSPO) courses in Atlanta due to increasing demand. As the only company in Georgia to have a local Certified Scrum Trainer, Peter Saddington, they want to bring even more value to the Agile community and local Atlanta companies who want to leverage Agile or Scrum to bring quicker development value to their software and services. Having a local CST gives Georgia companies a great advantage, as their employees can attend local courses without incurring the costs associated with travel. Peter Saddington is one of the 140 Certified Scrum Trainers in the world and about half of them reside in the United States. Peter Saddington is the first CST to reside in the state of Georgia. Saddington says, “Our local clients who are looking towards Agile and Scrum have greatly enjoyed having a local trainer who can service their needs without flying in another trainer from out of state. Most of our clients in Atlanta have private courses for their entire development teams and organization.”
You can quickly find local Atlanta Certified ScrumMaster classes, http://atlantascrummaster2013.eventbrite.com/and sign up as an individual, team, or company.
According to one of Action & Influence’s students, Mike Rucker, who recently took a Certified ScrumMaster course in Atlanta said, “I was very pleased to find a local group that offered such a wide choice in class days and times. It was very easy to find a class that fit within an already busy schedule.”
Other testimonials of Action & Influence, Inc. classes:
“Peter’s mastery of the subject matter coupled with his excellent presentation and communication skills made for an outstanding learning experience.” – Jim Olwine from Atlanta
“Peter REALLY did change my life. He provided such great instruction on Scrum and the duties of a ScrumMaster. He gave lots of clarity on my career direction. Great job!” – Aletha Hill from Atlanta
“VERY INSPIRING. [Peter Saddington] is one of the best instructors I have ever seen in my life.” – Parveen Yadav from Atlanta
“I can honestly say that the ScrumMaster class has changed my view on software development, and breathed welcome fresh air into some tired sails. I am genuinely looking forward to the second half of my career now, with hopes to embody in my work all that Peter laid out in the class and the skill set of a true servant leader in the technical world.” – Mike Rucker from Atlanta
A recent article from The Register was frickin’ hilarious. PERIOD. Snippets below:
A security audit of a US critical infrastructure company last year revealed that its star developer had outsourced his own job to a Chinese subcontractor and was spending all his work time playing around on the internet.
The firm’s telecommunications supplier Verizon was called in after the company set up a basic VPN system with two-factor authentication so staff could work at home. The VPN traffic logs showed a regular series of logins to the company’s main server from Shenyang, China, using the credentials of the firm’s top programmer, “Bob”.
“The company’s IT personnel were sure that the issue had to do with some kind of zero day malware that was able to initiate VPN connections from Bob’s desktop workstation via external proxy and then route that VPN traffic to China, only to be routed back to their concentrator,” said Verizon. “Yes, it is a bit of a convoluted theory, and like most convoluted theories, an incorrect one.”
After getting permission to study Bob’s computer habits, Verizon investigators found that he had hired a software consultancy in Shenyang to do his programming work for him, and had FedExed them his two-factor authentication token so they could log into his account. He was paying them a fifth of his six-figure salary to do the work and spent the rest of his time on other activities.
The analysis of his workstation found hundreds of PDF invoices from the Chinese contractors and determined that Bob’s typical work day consisted of:
The scheme worked very well for Bob. In his performance assessments by the firm’s human resources department, he was the firm’s top coder for many quarters and was considered expert in C, C++, Perl, Java, Ruby, PHP, and Python.
Further investigation found that the enterprising Bob had actually taken jobs with other firms and had outsourced that work too, netting him hundreds of thousands of dollars in profit as well as lots of time to hang around on internet messaging boards and checking for a new Detective Mittens video.
Bob is no longer employed by the firm.
It’s spring cleaning time. Time to clean out the closet and get rid of stuff that is either taking up space, not used, or just not worth keeping around.
I came upon a fully loaded packet of tons of certifications, broken out into 3+1 categories:
It’s funny. As I’ve accumulated a ton of paper. But it made me think. What’s the value?
In a overly-simplistic view, certification means I’ve done what is necessary to ‘complete’ a set of requirements.
It could be said that they don’t prove anything. And you would be right. For hiring purposes, they are basically used to filter candidates. But that doesn’t mean they’ll actually be able to do the job (with excellence).
For me, part of my spring cleaning is to continually provide excellent value to my clients and customers. To grow our business to the next level. Certification, at this level, has no real significance.
It felt very good to trash those papers (sans the degrees).
What do your new years resolutions / spring cleaning look like for 2013?
I believe that any ‘independent consultant’ or type of individual is an entreprenuer. It takes guts, gumption, and desire to go off on your own and build your own brand and take on all the risk. It’s scary and rewarding at the same time. Like driving 140+mph on a motorcycle. It’s scary but thrilling at the same time (not that I’ve ever done that…).
Entrepreneurs also have great ideas… good entrepreneurs share those ideas with others to get feedback. Sometimes though, you need a bit of a Non Disclosure Agreement to keep things kosher. How about a ‘lite’ version?
www.friendda.org – Love it. Perfect for using when you have an idea to share with others. Some highlights (italics mine) below:
This agreement is entered into this ___ day of ___ 20__ by and between _____________ (hereinafter “The Advisor”) and _____________ (hereinafter “The Keeper of the Idea” or “I”) regarding information The Keeper of The Idea is choosing to share with The Advisor (hereinafter “The Idea”).
WHEREAS I possess a bright idea that I am choosing to disclose to you, The Advisor, with the mutual understanding that you are my friend and that you will not screw me.
Manners of screwing include, but are not limited to:
This is a “warm blanket” agreement with which, by requesting your agreement to it, I am helping myself sleep at night by placing a small amount of formality on the sharing of The Idea. I believe The Idea will only improve as a result of having solicited your honest and clear feedback.
The term of this agreement shall continue until The Idea is no longer confidential.
This agreement has absolutely no legal binding. However, upon breach or violation of the agreement, I will feel free to do any of the following:
Sharing of some or all of The Idea with third parties may occur provided that you have cleared this with me and the third parties agree to the principles of the FriendDA.
Termination of this FriendDA can be executed by either party, but don’t be a douche.
You are acknowledging and agreeing to this disclosure by reading it. If you find any part of this agreement uncomfortable or confusing, don’t sweat it. We’ll talk about something else.
This is pretty interesting stuff. See the video below:
Easy Visualizations Streamline Problem Identification and Collaboration
ATLANTA – January 22, 2013 – VersionOne, recognized by agile practitioners as the leader in agile project management tools, today launched a comprehensive suite of agile visualizations in its Winter 2013 product release focused on enabling teams to more easily identify problems and collaborate.
“Visualization is becoming increasingly important in better understanding complex relationships. In the context of agile software development, our suite of visualizations can really help teams understand rapidly changing relationships and dependencies occurring during the software development lifecycle. With our Winter 2013 release, we’ve taken the next major step in simplifying project collaboration and making sure everyone on the team understands the impact their work is having on the overall program goals,” said Robert Holler, president and CEO of VersionOne. “This makes it much easier for teams to achieve their goals in a more holistic manner.”
VersionOne’s new visualizations help users identify impediments in their agile processes. They make it easier for users to understand and manage complex work item relationships and dependencies. Project dependency diagrams help team members see schedule anomalies, helping them to sequence work within a release. Additional improvements for Enterprise Edition include enhanced cross-project visibility for epics and streamlined epic breakdown, simplifying agile portfolio and program management.
For more information about the Winter 2013 product release, visit here.
You be the judge.
It’s here. The next wave of telepresence and freakishly weird robots with floating heads ‘bumping’ in the halls.
Have we gone to far? Or is this our future?
I have over 20 books that I need to read (re-read) this year… and I just bought about 7 more (in the mail) that will be hitting my doorstep in the next week. Every year I try to read at least 2 books per month. This year, due to my backlog, I pretty much have my entire reading backlog ready for 2013. While I was putting my book-stack together, something occurred to me… how all this reading… while a good plan… might not get done. And, according to previous experience and history, often it’s not. Sounds like a “failed project” correct? You’re absolutely right. Let’s break it down for a second.
Let’s be honest for a moment here:
I know that only through the act of EXECUTION and LEARNING will I truly know or understand my “capacity” for work and ability to complete the work “on time.”
We’re terrible at estimation. You do not “know” because you have never done.
Let me repeat that:
“You do not know (the estimate of anything), because you have not done it (before).”
Consider the massive implications on your work and business:
What a terrible existence to have!
We cover this a lot in our workshops and classes, but the main point is: We need to have opportunities to execute, learn, and grow. Only through experience will we be able to better give estimates. Find opportunities to execute, try, and learn. If your company doesn’t allow for experimentation, you will never have innovation.
Have a great kaizen 2013 my friends! Learn learn learn!
Project Management Institute’s – Project Management Body of Knowledge (PMBoK) Guide (Fifth edition) is now available! It’s an exciting an MUCH awaited news for (many) PMI volunteers who volunteered and worked hard on completing this!
I have been a part of this significant project since August 2010. I worked with a distributed, dedicated, talented team of project management practitioners from across the globe as a Content committee member. It’s an inexplicable experience to see your name listed in this Guide referred by worldwide practitioners and PMP aspirants. Thank you PMI and my amazing team for the support and this awesome chance!
The challenges that our team faced were tough but every team member was committed and made sure our work timeline was never impacted and delivered high quality output. There were multiple such teams working in parallel, and leads of those teams synchronizing all the work! I can’t imagine the number of stories rest of the volunteers must have to share.
To everyone who helped create this Guide and volunteered your expertise, time and probably sometimes sacrificed personal time – I personally thank you for your valuable contribution. If you stumble upon this post and have contributed, please share your story, views and journey.
If you have friends, colleagues, bosses – please spread the word around. (PMI members might already be aware about this). But, surprisingly I found MANY in the community who talk to me regarding PMP certification prep unaware about this. Project Management Professional OR PMP (R) is a world wide respected credential which is not restricted to JUST software development, but is common for non-IT fields and jobs – e.g.: Construction, Oil and Gas, Finance, Non-profits and many other domains.
If you are affiliated to a PMI chapter, make your chapter operations team and members cognizant about it. If you are a PMI-REP (Registered Education Provider), a trainer, consultant, blogger or simply a project management practitioner – this change affects you.
Share the news – by word of mouth, through emails, through twitter, Facebook – whatever media you can. Just help make the people making choice regarding project management as profession be aware about this change.
Check the Newly Updated Standards Availability page on PMI site, specifically: “Getting Ready for the Exam?” section with Study Recommendation and Updated Exam Schedule sections!
[Click for larger version]
Aparently if your project isn’t successful, it’s because YOU don’t have a PMP. Duh.
Sometimes I’m just amazed at the human mind. The human capacity. Human power. Human potential.
As someone whose roots are development and programming, I can really appreciate Santiago.
I’ll be following this kid… and look forward to celebrating his success! An inspiration for sure!
Sit down, stay awhile. Let me tell you a story.
Time and time again I sit down with clients, and I get to be in an Agile counselor position. Listening to a sob story over drinks and gruel of how it’s “Time to go Agile” after years of failing. Sometimes I take notes (if I have my handy pad), sometimes I write down stuff on whatever I can get my hand on.
Here you have a client… after spending 2 years and millions of dollars… the CIO called it quits… and made an executive decision right before new years… to cancel the project.
How do you count the cost? I might just make you sad. I’m sad… but not for long. It’s time for Agile. It’s go time.
Be it teams new to Scrum or ones that have been practicing scrum for a while, one of the common problems they face is: User stories carrying over multiple time boxes (sprints/iterations). The team simply can NOT finish the story and it drags on..and on..sprint after sprint.
As a member of ever growing agile community, I am subscribed to many discussion groups. Recently, one such discussion Can’t get to done, roll-over every sprint on Scrum Alliance Google Group caught my attention.
The origin of the problem can be at many places like: Ambiguous requirement(s)/stories, Stories not sliced enough, Business owner/PO availability, Technical road block, Team member availability etc. One of the common cause is “over commitment”. I’d like to share my recent experience about this specific problem and how I was able to address it.
Setting: Most of the team members were new to scrum/agile. 3 Sprints into the product development, our team was continuously moving more than a couple of user stories from sprint to sprint. Apart from the obvious problem of inexperience with user story creation and splitting, there was a zest in team which was leading to over commitment.
Having failed to try and discuss that problem in retrospectives, I had to wait for around 3 sprints to validate my assumption. (Yes, we progressed into creating better stories and got a little better at slicing them). After 3 sprints, I decided to try something different – I created a new backlog item “Spillover” stories for the next sprint. Since Thanksgiving was approaching people started talking about Turkey dinners and thus the “leftover” turkey sandwiches and all sorts of leftover recipe discussions were making rounds in office and internet. That inspired me to use the term “Leftover” stories.
At every daily standup, we would discuss about the “Leftovers”. And as it happens in every household, there came a day when the team got bored with leftovers. One of our developers broke the silence saying, “..I don’t like the term leftover/spillover you are using..”. The developer was concerned that the task board was not doing justice to the status of work completed in that story. That was the opportunity, I was waiting for.
We agreed to finish the standup and then discuss the issue. With everyone from the team present there, we looked at the stories, work history, capacity of every team member and turned the discussion into a retrospective. Everyone agreed that we had gotten better at describing the user stories, creating supporting documents/design/User interface. The team then realized given the time box, we were biting more than we can chew. For the first 3 iterations, we all were ignoring the fact as the team was forming, storming. It WAS a team commitment (or “lack of” to say NO to the product owner) issue.
This experience touched many aspects of the team’s operation, but mainly addressed the commitment issues. We do have some scrum certified team members but until we practice, fail, inspect-adapt and repeat the cycle, we are not being true to agile values and principles. It was a wonderful experience for me and the team and we all have made adjustments since then.
Many other scrum/agile experts offered excellent advice/response to that thread on Scrum Alliance Google group. I shared this story very briefly. I was delighted to see @RonJeffries responding to my response on the group as “Nice!” Made my day! [blackbirdpie url=”https://twitter.com/RonJeffries/status/268815166001532929″]
Thanks to @WoodyZuill for encouraging me to create this post out of a twitter conversation! [blackbirdpie url=”https://twitter.com/WoodyZuill/status/282132950387138560″]
If it helps, here are some of my User Story related valuable reads. I know it’s time to update that list! I am eager to hear your comments and stories.
I’m an audiophile. I love sound… really good sound.
I have tried many different types of headphones, from the big Beats to Skullcandy, and more.
For traveling, I found the holy grail of sound. After spending about 40 minutes trying on many different types I landed on these babies: Marley Zion + Comply foam tips. These headphones sound amazing, are cheaper than most other “high-end” and the sound quality is fantastic. Add in the foam tips for better isolation of sound… and you have a winning match. A nice addition is the ‘anti-tangle’ cord.
I don’t blog about stuff I buy at all… but these babies… hands down. Best travel headphones ever, and the reason I’m blogging about them is they seriously rock my socks. Gawd. Good sound is hard to find.
Hospital paperwork. It’s a beast. 12 different forms need signing before you even “begin” the labor process.
As I watched my wife sign her life away, what came to mind?
“There has GOT to be a better way of doing this. It takes so long to read through it, most all of it is standard (being pre-printed) and not customized. Therefore, there (can) be a way to (potentially?) review and sign this before we arrive.”
For those that have kids, you know that the process of having a child is just as unknown as software development can be. You don’t know the timing of things to align, you have human-constraints (docs/nurses), etc etc. Iterative baby-making is impossible, obviously, but at the tail end (having done this baby process before), I’ve already taken plenty of notes of where we can streamline the “hardware” (paper) issues.
This post is long “overdue” as I wanted to wait until things calmed down :).
Regardless, there are opportunities to improve things all around us. This is truly the spirit of agile. The best part of Agile is everyone working together, collaboratively, having fun, creating quality software. When you’re at that point, you’ll never want to leave. The gift of Agile is a blessing! Just like a new child.
[If you’re already an Agile Coach… see our tips section below]
Fewer things are more powerful in the arsenal of coaching than our words and how we use them. Words can not only empower and enhance our leadership, but they can also discount our profile and devastate those in charge. Words are the essence of our trade. The wise coach does well to recognize that fact.
There are two key considerations about words that we use and the things we say.
I found it fascinating as I was thinking and researching about this… that I came up with a list of issues that I not only found troubling… but issues that I, myself, have encountered among consultants, coaches, employees alike. It’s troubling to know that we live in such a negative work environment. That, my friends, needs to change!
[If you’re already an Agile Coach… see our tips section below]
In a lot of ways I see any type of ‘coaching’ a calling. Seriously. “Coaches” seem to be popping up all of the place these days… coaches in anything. I get it. There’s a market for it, but again, I believe is a calling. Something you’re compelled to do out of a deep desire for helping others. Nothing else.
I’m not talking about helping businesses necessarily… but helping people in LIFE. My opinion is this: A coach, helps people in life. It just may happen that you’re a coach for (fill in the blank) at a company or organization. That’s cool. But a coach helps people. Period.
Doing a little bit of fall cleaning I came upon a 1203-page book (yes over 1000+pages) that I had gotten in 2002 in preparation for one of my first government Program Management roles. I distinctly remember getting through the first 200-300 pages with my head spinning. I had already covered “Understanding Project Management,” “Defining Project Success,” and the “Roles of a Project Manager” and more. I hadn’t even really gotten to the meat-and-potatoes of being a good PM.
As my daughter circled me like a vulture looking for things to mess with as I cleaned she took a look at this book, tried to lift it, then literally pushed it aside for a smaller, and less heavy book. Her reaction made me laugh.
She wanted something she could handle… and so do I.
As I look back at my early days in the 90’s as a developer and manager I remember thinking about how daunting multi-million dollar programs were. How do you handle such things? Apparently there are Ph.D’s who write about this stuff.
But why was the entry fee so expensive and heavy? Back then, I didn’t know what the world had yet to offer (Agile).
Traditional PM processes and methods are super valuable. Agile isn’t here to change all of that per se… but rather add and re-contextualize those learnings and experiences to something a bit more flexible and adaptable.
“The illiterate of the future are not those who can’t read or write but those who cannot learn, unlearn, and relearn” – Alvin Toffler
As I say in my classes, “I’m not here to have you unlearn your previous experiences…but rather learn, and contextualize your experiences and how to apply Agile to your environment and culture.”
Now, I do, however want to ask the blogsphere: “Is there anyone that wants this almost 100% perfect condition book?” If you send me shipping cost, I’ll send it to you!!!