Test cases – it’s what QA guys and gals write when they aren’t testing. We figure some of our customers need a little boost when trying to incorporate their QA folks into the Axosoft tool, so here are a couple suggestions that might make life easier for the lovely faces at Quality Assurance.
Summon the Custom Items Tab
Surprise! You have a secret item type that you may not be using. It’s not enabled by default, so let’s first help you find this before we touch on test case management. First (assuming you’re both the admin and subscribed to our flagship product: Axosoft Scrum), go to Tools/ System Options/ General and you’ll see an unchecked box for Custom Items. Let’s check it and refresh.
Be sure your new tab is enabled like above. Voila, you now have access to a new item type. Please feel free to rename this to your heart’s content by going to Tools/ System Options/ System Labels. In this example, I’m going to rename this item, ‘Test Cases.’
Hopefully you are starting to see some of the pieces fall into place. As its own item type, you gain access to a new array of unique workflows, field templates, and custom items for test cases. So writing these cases and organizing them into the right folders should feel pretty familiar (as if you were creating defect or feature requests).
Splendid! I have my backlog of test cases, but how do I tie them to the corresponding user story, defect, or item? Ah, with another Axosoft feature you may not be using: Related Items. If you go to Tools/ System Options/ Details Panel, you can check the boxes across all the item types to enable this feature.
Once we save, the Related Items pane will appear at the bottom of the Details Panel. Now all you need to do is select an item and create the relationship between other items, so in this example, let’s relate to test cases!
Okay, so what does all this mean? It means your QA team should now be able to create test cases at will against a particular release. When they actually begin testing, each test case can move through the workflow until it is complete. QA can create worklogs for test cases as well, but Actual Duration won’t roll up across item types. If this is important to you, then check out a much simpler alternative below.
Alternative #2: Let’s just use sub-items
Should your testing be fairly straight-forward, consider using sub-items for your test cases instead. It’s pretty easy, all you do is select the primary item in question (probably a defect or feature), and nest a sub-item to represent your test case. The added advantage is that all your estimates and actual durations will roll up to the parent item. However, things might get hairy if you have a series of test cases you need to manage (that’s where the first option might be a better fit).
Best Practice: Templates of Test Cases
Our QA team must run a standard barrage of tests for each release. It’s the same set of tests, so they’ve created a folder within Axosoft that houses every single one of these cases. From here they just duplicate the folder…
Now, toss the items into the QA release…
And get to work!
We hope this illuminates your testing options with Axosoft. At the very least, you now have a new item type at your disposal and a means to relate items together.
Long ago, I was a project manager and senior engineer for a company undergoing a Change Transformation. You know the kind, where the culture changes, along with the process. The senior managers had bought into the changes. The middle managers were muddling through, implementing the changes as best they could.
Us project managers and the technical staff, we were the ones doing the bulk of the changes. The changes weren’t as significant as an agile transformation, but they were big.
One day, the Big Bosses, the CEO and the VP Engineering spoke at an all-hands meeting. “You are empowered,” they said. No, they didn’t say it as a duet. They each said it separately. They had choreographed speeches, with great slide shows, eight by ten color glossies, and pictures. They had a vision. They just knew what the future would hold.
I managed to keep my big mouth shut.
The company was not doing well. We had too many managers for not enough engineers or contracts. If you could count, you could see that.
I was traveling back and forth to a client in the midwest. At one point, the company owed me four weeks of travel expenses. I quietly explained that no, I was not going to book any more airline travel or hotel nights until I was paid in full for my previous travel.
“I’m empowered. I can refuse to get on a plane.”
That did not go over well with anyone except my boss, who was in hysterics. He thought it was quite funny. My boss agreed I should be reimbursed before I racked up more charges.
Somehow, they did manage to reimburse me. I explained that from now on, I was not going to float the company more than a week’s worth of expenses. If they wanted me to travel, I expected to be reimbursed within a week of travel. I got my expenses in the following Monday. They could reimburse me four days later, on Friday.
“But that’s too fast for us,” explained one of the people in Accounting.
“Then I don’t have to travel every other week,” I explained. “You see, I’m empowered. I’ll travel after I get the money for the previous trip. I won’t make a new reservation until I receive all the money I spent for all my previous trips. It’s fine with me. You’ll just have to decide how important this project is. It’s okay.”
The VP came to me and tried to talk me out of it. I didn’t budge. (Imagine that!) I told him that I didn’t need to float the company money. I was empowered.
“Do you like that word?”
“Sure I do.”
“Do you feel empowered?”
“Not at all. I have no power at all, except over my actions. I have plenty of power over what I choose to do. I am exercising that power. I realized that during your dog and pony show.
“You’re not changing our culture. You’re making it more difficult for me to do my job. That’s fine. I’m explaining how I will work.”
The company didn’t get a contract it had expected. It had a layoff. Guess who got laid off? Yes, I did. It was a good thing. I got a better job for more money. And, I didn’t have to travel every other week.
Change can be great for an organization. But telling people the culture is one thing and then living up to that thing can be difficult. That’s why this month’s management myth is Myth 34: You’re Empowered Because I Say You Are.
I picked on empowerment. I could have chosen “open door.” Or “employees are our greatest asset.” (Just read that sentence. Asset???)
How you talk about culture says a lot about what the culture is. Remember, culture is how you treat people, what you reward, and what is okay to talk about.
Last year I led an effort to implement time tracking for our teams. A quick warning is probably in order here:Never, ever, be the person who introduces time tracking at a company. You will be reviled before the gods and your name shall be stricken from the roles of the Agile. People will avoid you at parties, your kids will spurn you, and your pets will pee in your shoes. On the bright side, that Darth Vader helmet you have sitting in the closet will suddenly seem like a good thing to wear around the office.
So, now that we have that out of the way, back to our story. So I was leading this effort to introduce time tracking to all of the developers in our little corner of the company. The idea that had lead to this little misadventure was simple enough: if we used a time tracking tool we will get more detailed information about where time is being spent on projects than if we just make some educated guesses using excel spreadsheets (our existing mechanism). This will give us higher quality information and we will enable us to automatically handle things like capitalization easily.
That was the idea. If we ask people to report their time daily, they will give us a more accurate picture of the time that they are spending on the work. Simple enough. Our old system of excel spreadsheets made a lot of assumptions that probably weren’t true. For example:
- Everyone works an 8 hour day
- Everyone on a team works on a given project at the same time
- Team membership doesn’t change during the sprint
If you use those rules then you can come up with some rough estimates for how many hours the team put into any given project on a sprint by sprint basis. You have to assume that any errors or mistakes will just be averaged out over time. That makes the time tracking very simple to do, but it makes the finance guys twitchy. They get anxious because you are making a lot of assumptions about things that we all know probably aren’t true. And they really don’t like that “It all kinda works out on average” bit either.
So we decided to go down the path of detailed time tracking. Give up all hope ye who enter here. Detailed time tracking doesn’t assume much: every hour of the day must be accounted for. However there is one hidden assumption:
- Everyone will bother to take the time to accurately report their time for every day.
And there’s the rub. Very few people actually report their time accurately. First, you have to understand that they are ticked off that they are even asked to enter time. Second, they are very likely already entering their time in other places, like agile project management tools, HR vacation tracking tools, contractor management tools, etc. A single person might have to enter their time in 4 different systems! All you have done is add one more tool to the list and it is definitely not welcome.
So how do they use it? They either book all 8 hours of their day to the project and copy and paste every day, or they take one example day and copy and paste that. You aren’t going to get the real data, because the people using the system don’t really want to give it to you. At the end of a long day, nobody wants to have to sit down and try and figure out how much of their day was wasted in all those godawful meetings. They just don’t.
Oh, I suppose you could try policing it better – good luck with that.
You might come away from this little diatribe with the impression that I dislike time tracking. That’s not true. I realize there is a legitimate need for it in our business. However implementing it is much tougher than I realized and it’s very easy to find that the benefits really aren’t that clear at the end of it all.
Filed under: Agile, Process Tagged: benefits, time tracking
Könnt ihr euch noch an diese geraden Ski-Bretter erinnern, die schier nicht mehr zu bewältigen waren, wenn sie eine gewisse Länge überstiegen? Nur mit viel Kraft und technischem Geschick kam man heil den Berg hinunter.
1870 wurde in Norwegen der Carving-Ski erfunden und obwohl er deutlich leichter zu lenken war, konnte er sich am Markt (zunächst) nicht durchsetzen. Anfang der 1990er hatte jemand die Idee, dass es doch lustiger wäre, auf nur einem Brett zu rutschen, und hat das Snowboard erfunden. Den Berg auf einem stylischen und wendig geschnittenen Board hinabzugleiten, hat viel mehr Spaß gebracht, als sich mit diesen langen Ungetümen von Skiern abzuquälen. Skifahren war plötzlich was für unicolore Langeweiler, Snowboarden was für die coolen Bunten. Die Ski-Industrie geriet unter Druck. Als Reaktion darauf wurde begonnen, Skier – ebenso wie Snowboards – an den Enden breiter und in der Mitte schmaler zu machen. Wiedergeboren war der Carving-Ski, der den Skisport neu belebte. Denn ein Carving-Ski ist leichter zu lenken, ist wendiger und macht mehr Spaß, auch ohne viel Kraft einsetzen zu müssen.
Ganz ähnlich befruchten sich die Entwicklungsprozesse in der traditionellen Fertigungsindustrie (Hardware) und in der digitalen Welt der Software-Industrie. Die ersten Erfahrungen mit agilen Methoden wurden in der Flugzeugindustrie bereits 1943 gemacht, als die Alliierten eine schnelle Antwort auf die deutsche ‘Wunderwaffe’ brauchten. Zu Beginn wurde Software genau wie Hardware nach dem Engineering-Ansatz entwickelt: Plan – Design – Implement – Test – Wasserfall. Das war erfahrungsgemäß unzuverlässig in der Planung, teuer und vor allem hat es lange gedauert, bis man Feedback zu Entscheidungen bekam. Daher ist die Software-Industrie auf Scrum und andere agile Methoden umgestiegen und hat begonnen, ihre Produkt in Inkrementen zu entwickeln. Feedback wurde so nach jedem Schritt eingeholt und am Ende gab es ein Produkt, das wirklich einen Mehrwert lieferte. Und mehr Spaß macht es auch noch, weil die Entwickler selbstbestimmter arbeiten und in besserer Qualität produzieren können.
Das hat die hardwareproduzierende Industrie, aus Branchen wie Medizintechnik und Automotive, neugierig gemacht. Durch immer kürzere Innovationszyklen im Markt stoßen sie mit klassischen Projektsteuerungsmethoden bei der Umsetzung an Grenzen. Dank moderner Prototyp-Technologien lassen sich Ideen immer schneller in greifbare Ergebnisse verwandeln, mit denen Erfahrungen gemacht werden können. Der Weg zur Nutzung von Scrum ist frei und wird immer freier.
Mit Scrum ist jetzt auch die Hardware-Industrie wendiger und es braucht weniger Krafteinsatz, um Projekte erfolgreich umzusetzten. Und wer weiß, vielleicht verabschieden sie sich ja auch vom unicoloren blue-collar und werden bunter ;-)
- Brief an einen jungen Projektmanager
- Der Wille zur Lieferung Von Franz Zauner / WZ Online
- Agile Hardwareentwicklung mit Scrum
Durch Zufall bin ich vor Kurzem auf den Service www.iDoneThis.com gestoßen. Als ich mir anschaute, was dort geboten wird, habe ich sofort an die “Daily“-E-Mail bei Web.de gedacht. Wir schrieben dort am Ende des Tages an den Teamleiter eine kurze E-Mail mit den Dingen, die wir heute getan hatten. So wusste er, was der Stand der Dinge war. Leider wurde das oft vergessen, weil es keinen automatischen Reminder gab. Die “Dailys” wurden immer länger und das Reporting wurde zur Last. Die Idee selbst fand ich jedoch immer gut. In meinem Unternehmen nutzen wir Confluence, ein Wiki von Atlassian, in dem wir ein “Logbuch” haben. In dieses Logbuch schreiben wir unsere Aktivitäten des Tages hinein. Daher gefällt mir vielleicht auch die die Idee von iDoneThis so gut. Denn nun bekomme ich am Ende des Tages eine E-Mail und kann eintragen, was ich getan habe. Diese E-Mail wird einfach per Reply beantwortet. Am nächsten Morgen schickt mir iDoneThis eine E-Mail mit allen Aktivitäten des Teams.
So weit so gut – doch dann bin ich über die Kundengeschichten von iDoneThis gestolpert. Ganz besonders fasziniert hat mich die Geschichte von Bufferapp. Ich kenne Buffer als User und es gibt im Netz mittlerweile viele interessante Stories über diese kleine Firma. Die Story, die iDoneThis über Buffer erzählt, ist für einen Scrummie verblüffend: Sie sagen, dass Buffer die Daily Standups durch iDoneThis ersetzt hätte (den ganzen Text findet ihr hier):
“As a remote team, Buffer needed a better way to stay on the same page. Previously, everyone would get on a daily group Skype call in which each person would take three minutes to talk about what they did, how their co-workers could help, and their improvements. With the team growing larger, the standup process wasn’t scaling over Skype, as they began to have to deal with Skype malfunctions, different timezones, and ever-increasing meeting lengths. Holding traditional standups over video chat also meant that “if you jump in and talk about something that somebody just said, you’re basically interrupting their three minutes. So what we would actually do is not ask that many questions.” They tried email, but it became a hassle as email threads got longer and longer, and each new message bumped the thread in everyone’s inbox and created another alert. Buffer turned to iDoneThis. It’s a way to understand what teammates are working on, and every time I read people’s iDoneThis, I feel connected with the team. With iDoneThis, rather than having to spend an hour in a meeting, you only have to read your email. We send an email to your team every evening asking, “What’d you get done today?” Just reply. The next day, we send a single email digest to everyone on the team with the contents of what might otherwise take a lengthly and tiresome meeting. Leo remarks, “It allows us to track performance, which easily gets lost in a chat room or an in-person standup. If new people come on board, they can look through and see what has been worked on. And of course, it’s amazing to keep in sync with everyone, working as a remote team. iDoneThis is invaluable to us and has changed our productivity for the better.”
Unser Logbuch hat gegenüber dieser Lösung einen Nachteil: Ich muss nachschauen, was jeder getan hat. Hier bekomme ich automatisch einen Überblick. Kann diese Lösung das Daily Standup ersetzen? Ich bin mir nicht sicher – mit meinen Kolleginnen in Baden-Baden treffe ich mich jeden Morgen zum Daily Scrum per Google HangOut (Skype war einfach nicht verlässlich genug) und es ist großartig. Diese 15 Minuten sind für uns sehr wichtig. Was wir nicht haben, ist ein Board. Aber wir brauchen es auch nicht, denn es geht bei unseren Dailys nicht ums Reporting, sondern einzig um die Zusammenarbeit. Wir stellen bei unserer Arbeit bereits fest, dass das Nicht-Zusammensein schnell Fremdheit erzeugt. Mir immer wieder in Erinnerung zu rufen, wo die anderen gerade sind – selbst mit unserem Einsatzplaner LaLinea (ein selbst geschriebenes Einsatztool) verliert man schnell den Überblick. Vielleicht kann da ein Tool wie iDoneThis helfen. Probiert es für Euch doch mal aus. Lasst uns wissen, ob es hilft.
- The 10 things I use most:
- Impact of collocation on team effectiveness – Study
- Boris is in Belo Horizonte and Recife, Brazil
There you are, in your tenth meeting of the day. You haven’t even had lunch, just one meeting after another. You’d skip the meetings, but you are required and half the meetings are yours anyway. You finish the day without having accomplished one single thing (except a bunch of meetings). Your todo list has only grown longer and the only time remaining is after hours (because nobody can schedule a meeting then). If this is you, then you might have superman syndrome.
It’s pretty common in software development. The nicest people get sucked into it (no, really, they’re too damn nice). You are competent, eager to please, and really can’t say no. It’s a great ego boost – you are needed! Well, I’ve got some bad news: you’ve got Superman Syndrome.
That’s right, you got it bad. Now sit down. This is where we get to play product owner. Product owner of your life. Write down that list of all thing things you have to do. Go ahead, put it in priority order. That’s right, it’s not easy. Product ownership is a bitch. Good, now cancel all your meetings. I know it hurts. Do it anyway. Send some polite excuse about being behind in your work (because it’s true) and you’ll catch up with them later (maybe never).
Now take that one thing at the top of the list (it is just one thing, right?) and get to work. Here’s the new rule, you don’t get to work on anything else until that thing is done. Take comfort in the fact that you are working on the most important thing that you could be working on. No one can fault you for that. You see what we are doing is limiting your work in progress (WIP). Limiting the amount of work you take on is like kryptonite to Superman Syndrome.
While we’re at it, let’s just turn outlook off. Yeah, completely off. You have a WIP limit here too: twice a day. Once before lunch and once before you go home. That’s it. That’s all.
While we are having so much fun setting WIP limits, we might as well put a WIP limit on your meetings. That’s right, nobody can reasonably expect you to do your job AND attend every single meeting: so don’t. Set a reasonable limit (no more than 2 hours of meetings/day). That way you are available if the issue is REALLY important, but otherwise, they’ll have to just get along without you. Again, polite apologies all around.
Try that on for a while and see how that works for you. Come back and chat with me when you think you are ready to change your WIP limits.
Now to take my own advice…wish me luck.Yours truly, Superman
Filed under: Agile, Coaching Tagged: Coaching, meetings, superman, time management, WIP, work in progress
- Don't rely of vanity metrics : number of likes , followers , visits on your product idea page is no sign of commitment
- Be aware of false positives : don't count your family and friends in the measure of your success
- Customers are experts of the problem : if you want to build a successful solution, listen to real problem of customers instead of your ideas of the problem.
- Listen and observe, don't push your assumptions
- Customer is expert of the problem, they will find the most adapted solution
Interview Questions are Powerful Questions The Lean "Gemba Walk" turned in "Get Out Of The Building" activity in Lean Startup ( as Lean Startup Machine initially defined it ) . Briefly it invites entrepreneurs to get into the "customer arena" and proceed to customer face-to-face interviews instead of running fancy marketing customer study analysis from company's ivory tower. To have effective feed-back , there is a key condition : prepare the customer interviews and ask the right questions right. What are the patterns of good customer interviews questions ? Here is a quick hint :
- Don't ask closed questions ( that will get a Yes/No answer). Closed questions are the main source of false positive and you won't get much of the binary choice.
- Ask "Why", "How", "What" questions to avoid closed questions. Don't hesitate to repeat them .
- Invite to storytelling: ask customers to tell their experience in the domain you're interviewing about
- Be interested about their problem , customers talk, you listen .
For those people that are familiar with coaching the interviewing pattern should ring a bell. Because what is asked from entrepreneurs to build a solid delighted customer base is to have a customer and market ... coaching attitude .
Emerging Marketing Approach
Traditional Marketing may teach us that the key to success is to create a need. Today's world of frugality that has a tendency to run away from consuming behavior is probably not aligned anymore on this vision.Marketing of tomorrow that will bring make entrepreneurs successful might shift from "owning the market" to "coaching the market".And "create the need" will definitively shift to "make customer realise they have a need that they were not truly aware about". A completely different story.
I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves. Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.
It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.
Filed under: Agile, Tools Tagged: fitbit, measure, Metrics, Tools
I’ve talked a lot about the rigors of finding and resolving impediments for a team. There is one thing that I have left out: the people part. I learned this lesson at a conference that I was co-hosting. I had been in charge of setting up the food for the event. Getting the caterer, arranging for meals, that sort of thing. As you might imagine, it’s a pretty tough job to satisfy the dietary requirements for a very large group of people. I learned of whole categories of food allergies and needs that I had never even imagined existed! There was a little bit of every imaginable combination. Everything from your standard gluten free diet all the way to lacto-ovo-pesca-leguma-veganitarians (OK, I made that last one up).
We did the best we could to satisfy the needs of most folks and pretty much called it good. About halfway through the conference, someone mentioned that there was no food that fit in their dietary needs. I expressed my sympathies and referred them to the grocery store around the corner. I really didn’t give it another thought. A few minutes later, I heard the same complaint made by the same person, but this time the reply was, “I’ll get you something, I’ll be right back” And that person ran off to the store themselves. Wow!
I was humbled. The difference between my reaction and theirs was the difference between someone who could empathize and take action to resolve the impediment, and someone who couldn’t. The lesson I learned that day was that in order to help people with their impediments, it takes empathy. You have to feel their need, and be receptive to doing anything to help them out. I think I had missed that before. That willingness to serve the needs of others is really important. All the strategies in the world for resolving impediments won’t help anyone if you don’t care.
Filed under: Agile, impediment Tagged: Impediments, leadership
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 2: REVISITING INFLUENCE
How do you observe yourself or your colleagues influencing each other? What kinds of influence do you see as critical for lasting positive changes?
Leave a comment on this blog or email us at firstname.lastname@example.org
[1:40] Sharon is working with the leadership of a large non-profit with an enormous number of volunteers, who do the real work of the organization.
[4:00] Working with volunteers is all about building a sense of community and purpose to motivate people to do what needs to be done – all through “influence”.
[6:15] Power and influence are orthogonal.
[8:05] Compliance and influence are also different things.
[10:20] Motivation comes from within – it doesn’t get applied from outside. You can’t inoculate people with it.
[15:55] The model Sharon’s looking at currently looks at 6 types of influence.
[20:20] Convincing, selling, and so on, is also not influence. And influence will get you more mileage.
[22:23] Benefit must accrue on both sides for change to last – this is real influence.
[24:30] You can give feedback if you can do it with caring and respect. If you don’t care and respect the other person, don’t bother. The same is true of influencing – do I care about this person?
[28:00] An important element of influence is creating an environment that supports what you want to have happen.
You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
The Kanban Litmus Test is our new guidance to help you assess "are we doing Kanban or not?" and to evaluate whether other who claim to be doing have actually reached a stage that would reflect the sort of impact that we saw in early implementations almost a decade ago.
For a corporation setting out on a large scale Kanban implementation, there is the inevitable question of, where to start? Typically, clients want to run a pilot on a single service delivery workflow but which one to choose? Firstly, we must find a service delivery workflow that is appropriate for a kanban system. [See the first post in this series on appropriateness of kanban systems]. To do this, we might view the organization through The Kanban Lens in order to identify suitable services. Secondly, we must assess whether this service is a good choice for a place to start Kanban.
In the Kanban Coaching Professional Masterclass, I teach coaches and those leading Kanban initiatives how to assess the appropriateness of the Kanban Method and the appropriateness of applying a kanban system within an organization. This is the first of a series of blog posts on appropriateness and getting started with an enterprise scale Kanban initiative.
I was asked the other day, “Do you use Scrum at home?” It’s not the first time that I’ve been asked this question. The honest answer is: no. Oh, I’ve used bits and pieces here and there. I’ve put together a taskboard to track work on the occasional big household project. I’ve even built a backlog from time to time. But that is about the extent of it. I’ve been married for nearly twenty years – I’m not about to screw it up with Scrum or any other method for that matter.
You won’t find me standing around with the kids doing a daily standup. There is no weekly planning meeting on my family calendar. And the only retrospective that I do is after getting caught leaving the toilet seat up (“Doh!”). Nope, I’ve got to be honest, my household isn’t very agile.
You might ask, “Why not?”
Dang, that’s a really good question. I’m not sure that I have a good answer. Maybe I just want to leave all that stuff at work. But if that were the case, then why do I go home and write this blog? No, that’s not it. Maybe there really has been no structure modelled in my family life before. In fact, the very idea of doing that kind of “work” at home makes me cringe a little bit. I guess I feel like we have things under control. Maybe I don’t even want that control. It’s really hard to say.
I think there is value in sharing the practical time management techniques that I use at work with my kids. I didn’t hesitate to introduce them to pomodoros when my daughter was struggling to stay focused on her homework. It felt really good to be able to introduce her to a tool that would help her be successful. She loves pomodoros! The kids like all the fooling around that I do with self-experiments around the house (“Hey! Look at Daddy!”). They always want to know what kind of nutty thing Dad is doing this week.
However, I’ve never felt a compelling need to have any kind of formal family meeting at all. Call me a bit waterfall. I guess when it comes to my family I only want to give them the techniques that they need for the problems they have. I don’t want to burden them with a framework. Got a problem with focus? Use pomodoros. Does the problem seem too large? Break it down into stories. No progress? Try iterating.
When I can provide a helpful technique that solves their problems (agile or not), I feel like Superman. Seriously folks, there is no better feeling in the world. There is no preaching. I don’t lecture them on the perils of waterfall. To my kids a waterfall is something you ride a log down at Disneyland. I aim to keep it that way as long as possible.
I guess, in retrospect it’s not such a bad approach for introducing agile practices for anyone, regardless of whether they are in your family or not. In fact, why would you treat a team any differently than your family? Aren’t they just that – your extended family? Can we use this to inform how we approach introducing Agile Practices to our teams?
Maybe we just introduce them to the tools they need to solve the problem that they have in the moment. Perhaps that’s how we start. That’s how we demonstrate value and earn trust. Not by dumping some framework they must comply with on their heads.
Hmmm….I think I’ve been doing it wrong.
Introduce agile practices to your team like you would to your family. Give them only what they need and let them figure out the rest.
Filed under: Agile, Coaching, Teams Tagged: Agile, family, practices, Scrum