2007 – I had been working for several years as a traditional Project & Program Manager in the .com division of a Fortune 500 company. There was a constant cloud over my head. I didn’t really enjoy my work and had been soul searching for some time. I had been exploring and reading a lot about better ways to get work done, and came across this thing called Scrum. So I signed up for a CSM class, took it, was enlightened, and excitedly told my Director all about it. He gave me the green light to try it out on a small project or two, which I did. Somewhat surprisingly, these two projects were wildly successful. The productivity was more than triple the traditional Waterfall projects, the number of defects introduced was almost zero, our customers loved the quick feedback and the ability to change their minds whenever, and the buzz was that this was actually something fun to be a part of.
I was quickly named as the Lead Scrum Master, Coach, and Trainer for all things Agile, as I was the only one who knew anything about this stuff at the time. Others started inquiring about getting on one of these Scrum teams, how they could get training, how to get started, rooms, projectors, supplies, tools, etc.. I recruited some help, and we made incremental progress, getting more and more traction as we went along. It was very cool to be part of something like this. That’s not to say everything was perfect; it wasn’t. Our PMO still managed scope poorly, jamming too much work into a small pipe. Alignment at the Program and Portfolio levels wasn’t really there yet. Not everyone wanted to be part of a Scrum team, which we just kinda assumed they would. The culture held us back in certain areas. Not all the Management level was on the same page. We didn’t have any budget for external training, which is why they used me; I was ‘free’. But at the end of the day, enough folks were convinced this was something that was valuable that we expanded the initiative.
2011 – I made the decision to leave the big company I had been working for to become an Agile Consultant at a small Midwest consulting firm in their Agile practice. It was an exciting time for me personally. I thought I’d be able to work with different clients, and help them do the same thing I did in my previous experiences. The opportunity for growth appeared to be huge. But as time went on, the work turned out to be intermittent at best, and we were struggling to gain any new business. Building up an Agile practice is not only hard work, but takes time, money and patience. The hard work part of the equation we had, but the rest was pretty limited. Once my 6 month Agile consulting engagement with our one and only customer was completed, I found myself in a bit of a pinch. We didn’t have another client for our Agile consulting services, and in order to stay on with the firm, I had to take whatever came my way. In this case it was a traditional Project Manager position with an insurance company. And yes, they utilized the Waterfall method of getting work done. The fact that I had a PMP after my name, and several years of good experience qualified me for the interview, which I passed. I needed the work, and so did my firm. The hourly rate was good, so I took it. I would soon come to find out what a nightmare I was in for.
It had been years since I last managed a Waterfall project, and those memories were less than fond. So I brushed up on my MS Project skills, dusted off the old PMBOK, reviewed the organization’s procedural guide for project management, and talked with some of the other PM’s at this new organization I’d be working with. None of them seemed too thrilled with their jobs, which was a red flag that I chose to consciously overlook.
First week at the new gig was fine. Pleasantries, meeting the players, getting comfortable, reading procedural manuals, software downloaded, all that stuff you do the first few days. Then I got assigned as the Project Manager for three projects (one new and two in-flight). I was gung-ho and ready to show them what a great Project Manager they just hired. I was expected to manage the schedule, cost, and resources, which were all fixed. I would soon come to find out that this was not the case, but not in the way you might think. Managers would intermittently pull resources from in-flight projects to work on other higher priority projects or bug fixes, with the same expectations of us finishing the contracted scope and time deadlines for the projects. Of course, the beautifully constructed Gannt charts went down the toilet. I spent way too much time fighting for resources, adjusting the schedule, dealing with a multitude of dependencies, and discovering issues and impediments much too late. As each project team member was working on an average of 4 projects simultaneously, context switching was through the roof. The ‘throw it over the wall’ mentality was well established. There was a rush to get tasks completed on one project and move on to the next project. Back and forth, ad infinitum. Waste, frustration and technical debt; a vicious and unhealthy cycle that just dug deeper holes. I was also the person in between the customer and the team, and as such, was required to know everything, all the time, and communicate it all to everyone at least once a week in a high stakes status meeting where key team members would often either not show up at all, respond to emails on their phones if they did, and the internal customer would freak out about dates, scope, cost and risks. They didn’t want to hear about reality. Needless to say, those status meetings were hell. I was constantly on the hot seat, folks waited to be told what to do and when to do it, and when things fell down, the finger was squarely pointed at me, the Project Manager. This was not natural and it wasn’t working. The concept of a true Team was missing. It seemed that folks didn’t care about one another or the success or failure of the projects. I talked with a couple of my peers about their experiences, and while they recognized the same situation privately, they were not willing to call things out publicly. I presume this was based in fear. That cloud sitting over my head had returned. I knew the situation wasn’t sustainable, but I kept on for another couple of months anyway. It got to the point where my mental health was worth more than a paycheck, so I respectfully resigned. But just before I did, I had a chat with the Director of the Project Management Office. I talked with him about Scrum, and all the ways it could change things for the better, even in a regulated environment with hard completion dates. I explained it would be a big effort to transition to Agile. And that it wouldn’t happen overnight. That it would require investment. But over the long term, it was the smart thing to do and absolutely necessary to remain competitive. He listened, but wasn’t interested at the time. Too much critical stuff in flight to introduce such a change at the moment. Maybe later, he said. So that was it. At least I had tried.
2012 – Happy ending to this story… I soon landed an Agile Coaching gig with a larger consulting firm on the east coast, shortly after the aforementioned Waterfall debacle. The client was open to new ideas and eager to transform their organization to Agile/Scrum/Lean/XP practices. We made a lot of headway by investing in people, teams, training, Agile Business and Technical Coaches, various tools, and open collaborative spaces. Upper and middle management created a culture of trust and transparency, and became true servant leaders to the teams. The business side began working closely with the technical side. No more throwing stuff over the wall and moving on to something else. We would succeed or fail as a team, not as individuals. Huge changes in a short period of time, yielding huge gains in productivity, efficiency, and quality. And most importantly, we gave the customer what they needed, not what they asked for 9 months ago. Customer involvement throughout was one of the key factors of this success.
During my tenure as an Agile Coach at the aforementioned consulting firm, we chose VersionOne as our ALM tool. A VersionOne Coach and Product Consultant came in and helped us to configure the tool to fit the client’s organizational structure, showed us how to administer it, and trained a large group of IT and business folks on how to use it over the course of about two weeks. I got to know this VersionOne dude. We worked together on a few issues, and kept in touch. Soon there was an opening for an Agile Coach at VersionOne, and the rest, as they say, is history. I’ve been an Agile Coach & Product Consultant with VersionOne for about a year and a half now. The access and influence I’m afforded in helping organizations moving the Agile needle is amazing. It’d be hard to find this kind of opportunity with any other company. At the end of the day, I like helping people. And in my current role, it happens to be a perfect fit.
What happened in the mid 1980s? Previously women were in the hi-tech industries at the same rates as any other industry - but then it all changed. Women fled the compute sciences field. Is this the rise of the computer geek era?
Was it the geeks that ran the women away? Or was it the lack of women that attracted the geeks? Was there cause and effect or just an interesting correlation?
Planet Money has an interesting investigation and some answers - give it a listen.
When Women Stopped Coding :: Planet Money - NPR
I’m 35 and only recently I truly nailed what drives my life — it’s “creation”. When I create something meaningful I feel really great. My creations are not tangible in most cases, like poems, songs, design solutions, new product features, articles, books and blog posts. In general I think creation of anything that lasts is a good way to spend your life.
Deep immersion into a working process turns off everything around. You suddenly ignore all external sounds, you don’t feel how minutes and even hours passing by, you don’t notice poor lighting and reject timid body requests. Then you wake up and check the result. Maybe it’s not perfect, maybe it’s just a start of something significant, maybe you will throw it away in several days after critical examination, but nevertheless you have a sense of achievement. You’ve just completed a thing that may be a part of your legacy.
Can you write? Can you invent a software that changes people lives? Can you build a house? You never know till you try. Your life passion is not “programmed”, it should be “discovered” via experiments and achievements. Moreover, public recognition in many cases is not a good indicator of your achievements. Your personal feelings do matter. When you achieve something and enjoy the process, it is a good signal that your experiment was successful and you should keep going. When you spent quite a lot of time on, let’s say, quantum physics with no clear results and theoretical constructions bored you to death, maybe you should try something else (or maybe you just have a depression, but it’s curable).
Any startup and any ambitious mature company should hire as many creators as it can. These people are enthusiastic, active and relentless. They are the engine of a company. They keep learning, experiment a lot and failures are just a part of their working process. Every team desperately needs at least one creator, otherwise it will be mediocre at best.
How to discover a creator? It is relatively easy to do. Usually they can have something from the list below:
- Side products (frameworks, apps, whatever)
- Blog, articles, books, whatever
- Hobbies related to creation (painting, robots construction, fancywork)
- They usually like LEGO and Minecraft (this option alone is not 100% proof that a person is a creator)
Consumers are all around. We all consume books, movies, TV shows, cars, food, etc. How many of us transform all these consumed information, experiences and skills into something meaningful? Surprisingly, creators are quite rare. It’s incredibly hard to find one and align his goals with company goals. Sometimes they are not polite and hate everything that blocks or slow downs acts of creation. They will not tolerate political games and bureaucracy. Most attempts to cheat them and exploit them will fail in the long run.
We need to build companies that promote honesty, creation and learning. I’m here to create. You?
Over the weekend, I attended the Nodevember developer conference in Nashville, TN. I was fortunate enough to speak and showed a demo of how we can break the shackles of our big, bloated IDEs in software development. Now, that’s not to say there’s no value in IDEs… but I don’t need to explain my complete position, here. You can watch the video of the talk, if you want to know more. One of the things I say in that video, though, has stuck with me for the last few days:“You Are Not Your IDE!”
I said this with purpose, as a continuation of the conference’s opening keynote speaker saying, “You are not your code,” and as a play on the “Tyler Durden” character and his “you are not …” lines from the movie, Fight Club. The more I think about this line and the rant that I wanted to go in to, the more important I think this idea is. But I keep coming back to it, not because I think your favorite IDE is worthless… but because “you are not …” is a two-way street.The Way It’s Always Been
We often get stuck in a rut as human beings – not just as developers, but as humans in general. We fall in to comfortable habits, and we do them without thinking.
I moved in to my current house almost 10 years ago. While settling in, my dad bought me a large set of drill bits and other attachments knowing I would need them. A few hours after getting the new bits, I needed to put a hole in something. YOU WON’T BELIEVE WHAT HAPPENED NEXT! (LOL – sorry. couldn’t resist a bit of link bait. :D) After figuring out what size drill bit I needed, I went searching through the old tools in my garage, hoping to find a small pack of drill bits that I knew I had … completely forgetting that I had this brand new, well organized, right-in-front-of-my-face case with 90+ bits and other attachments in it!We All Have Habits
It wasn’t that I liked my old drill bits better. In fact, I didn’t like them much at all. I remember thinking that I hoped they would survive the job and be the right size. I had new drill bits, but I had already forgotten about them because in the short time that I went from getting them to needing them, I fell in to old habits and comfort – even if that comfort was more painful than what the new thing would have been.
It’s easy for us to forget that humans have ingrained habits – whether it’s ourselves or others around us. It’s easy to fall back in to our comfort zones. Things that are familiar are more comfortable than things that are not, even if they are not better.
It’s no wonder, then, that people still use older tools from bygone times. We get comfortable with them and we have a hard time putting them down (I use Vim, after all… one ancient editor!)NEW TOYS!!!!
I like new tools and new things in software development. It doesn’t mean I don’t get stuck or that I always have time to try new things, but I do make an effort. And let’s face it – half the time that I want to try a new tool is just because it’s new. It may or may not solve any problems or do something better, but it’s a new toy! And I want to play with it!
There’s not necessarily anything wrong with this. Allowing myself to play with the new, shiny development tool toys gives me an advantage at times. It helps me to find tools that really do help me improve in some way. This talk that I gave at the conference? It was full of the new toys that I have been playing with and using for the last year, or in some cases many years.
But new toys aren’t always what we need. Sometimes, the old toys that we keep going back to out of habit, or the toys collecting dust in the bin, are the ones that we really need.The Old Toys Are Nice, Too
One of the problems with new toy syndrome, is that we forget about other people that just need to get things done. We forget about comfort zones and familiarity. We forget that not everyone can be as productive as we are, with something new. Not everyone has time to play with new toys and learn new things, either. I don’t event have that much time, in spite of what it may look like to some people.
When we forget about the nice old toys, or even the toys that are kind of broken but still help someone get the job done, we sometimes get a little mean. We point and laugh at the kid with last year’s toy, while we run off with our new friends playing with this year’s toy. But, that’s not ok.You Are Not …
My Fight Club ranting moment had a point – being overly attached to our tools, our language, our development environments, our whatever… that can do damage in a lot of ways. But the “You are not …” meme is a two way street. It’s true that you are not your IDE of choice. But, what is your IDE of choice? Is it an IDE of old? Is it a vendor-specific IDE? Or is it a conglomoration of command line tools that you’ve strung together, as I’ve shown in the above video?
You are not your code.
You are not your programming language.
You are not your IDE, or command line tools!
You are not the contents of your GitHub repository!
You are not … !!!
It’s easy to think we’re doing better than others because we’re playing with the “cool kids”. It’s easy to laugh at others and think less of them, too. But it’s far more valuable for everyone – ourselves included – if we remember that level of comfort and familiarity in the old tools and techniques. It’s also equally as important to remember that we are not the new tools that we are using. We are not here to hang with the cool kids, either. We’re here to do our jobs; to solve problems and hopefully make the world and the lives of other people better. If we can remember that, we can empathize and we can relate. We can show people the new things and share our new toys.
And maybe… just maybe we can even help someone else become productive with the new tools that we’ve found.
But not always. And that is ok.
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Der Deming Cycle begleitet mich als Mensch schon ein Leben lang. Die dahinterliegenden Begriffe sind umgangssprachlich schnell erklärt (Für eine intensivere Auseinandersetzung siehe http://en.wikipedia.org/wiki/PDCA oder die Vielzahl der Bücher zum Thema.)
Plan – Lege fest, wie Du das Ziel erreichen willst.
Do – Zerlege das Ziel in kleine Schritte und führe diese aus.
Check – Analysiere das Ergebnis dieser Schritte.
Act – Führe korrektive Maßnahmen durch und mache diese zum Bestandteil des nächsten Durchlaufs.
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Das Konzept ist ein Grundbestandteil der Scrum Methodik und somit ein fester Bestandteil unserer täglichen Arbeit. In den Estimation und Sprint Plannings #1 & #2 planen wir, WAS getan und WIE es getan werden soll (Plan). In den Sprints setzt das Team diese Planung durch die Ausführung von Tasks um (DO). Im Review und in der Retro sehen wir uns an, wie es für die Kunden und für das Team gelaufen ist und was wir in der nächsten Runde besser machen können (Check). Diese konkreten Verbesserungsvorschläge nehmen wir mit in die nächste Runde, um wieder Dinge ein Stück weit zu verbessern (Act).
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Es ist ein ständiger Kreislauf. Als Metapher dazu fällt mir der ständige Kreislauf der Natur ein. Der Frühling ist der Anfang: Es fangen die ersten Triebe zu sprießen an und die Luft ist voll von Hoffnung auf Wachstum und darauf, in diesem Jahr ungeahnte Größen zu erreichen. Im Sommer beginnt der Wettbewerb der Schönsten: alles blüht und zeigt, welche Pracht die Natur entwickeln kann. Im Herbst ist Showtime: Was wurde denn wirklich produziert und wer trägt die meisten Früchte? Der Winter ist die Regenerationsphase: Es gibt eine Ruhepause, in der die Natur ihre Kräfte sammelt, um im Frühling den Zyklus wieder neu beginnen zu können.
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
So und nun folgendes Szenario: Mutter Natur sagt eines Tages als Personifikation des gesamten Kreislaufes: “Puh, immer dieser Kreislauf und dieses ständige Verbessern und Verändern der Gene und das Mutieren. Ach lassen wir das doch einfach sein. Wir haben das doch schon so einige Jahrmillionen Jährchen gemacht, langsam sollte ich den Dreh ja raus haben, ich hör jetzt einfach auf mich zu verändern. Ich hab mein Ziel erreicht.”
Klingeln da nur bei mir dir Alarmglocken oder geht das anderen Lesern auch so? Ich habe den starken Verdacht, dass diese Maßnahme kein gutes Ende für die Natur (geschweige denn für uns Menschen) haben würde. Was würde mit unserem Ökosystem passieren, wenn Bäume sich entschließen würden, sich nicht mehr an ihre Umstände anzupassen und sich zu verbiegen, um das Sonnenlicht zu erreichen? Was würde passieren, wenn Blumen nicht immer neue Geruchsstoffe entwickeln würden, um Insekten jedes Jahr aufs Neue anzulocken?
Das ständige, nie aufhörende sich Verändern ist ein stetiger Bestandteil der Natur, dem wir unser Überleben verdanken. Mehr noch, wir Menschen selbst befinden uns in einem ständigen Veränderungsprozess, der unser eigenes Überleben ermöglicht. Eine Lebensphase wechselt die nächste ab. Was gestern noch unglaublich wichtig war, kann morgen schon bedeutungslos sein.
In diesem Sinne, feiern Sie in Scrum den Herbst (Review) und nutzen Sie die Winter (Retrospektive), um sich Gedanken zur Optimierung der nächsten Iteration zu machen – aber bitte vermeiden Sie es, das Ende von Scrum zu suchen. Das Ende von Scrum als iterativer Prozess wäre das Ende der Weiterentwicklung. Die Weiterentwicklung ist jedoch der größte Vorteil auf einem sich verändernden Markt und hilft, jede Schwierigkeit zu meistern.
After my previous blog entry about the support of Objective-C, you could get the impression that we’re fully focused on Unix-like platforms and have completely forgotten about Windows. But that would be a wrong impression – with version 3.2 of the C / C++ / Objective-C plugin released in November, 2014, support for the Microsoft Component Extensions for Runtime Platforms arrived in answer to customer needs. The C-Family development team closely follows discussions in the mailing list for customer support, so don’t hesitate to speak about your needs and problems.
So what does “support of Microsoft Component Extensions for Runtime Platform” mean? It means that the plugin is now able to analyze two more C++ dialects: C++/CLI and C++/CX. C++/CLI extends the ISO C++ standard, allowing programming for a managed execution environment on the .NET platform (Common Language Runtime). C++/CX borrows syntax from C++/CLI, but targets the Windows Runtime (WinRT) and native code instead, allowing programming of Windows Store apps and components that compile to native code. Also could be noted there is not much static analyzers capable to analyze those dialects.
So now the full list of supported C++ dialects looks quite impressive – you can see it in the configuration page:
And this is doesn’t even count the C and Objective-C languages!
You also may notice from the screenshot above, that now there is clear separation between the ISO standards, the usual Microsoft extensions for C/C++ (which historically come from Microsoft Visual Studio compiler), and GNU extensions (which historically come from GCC compiler). The primary reason for the separation is that some of these extensions conflict with each other, as an example – the Microsoft-specific “__uptr” modifier is used as an identifier in the GNU C Library. To ease configuration, the plugin option names closely resemble the configuration options of GCC, Clang and many other compilers.
But wait, you actually don’t need to specify the configuration manually, because you can use the build-wrapper for Microsoft Visual Studio projects just like you can with non-Visual Studio projects. Just download “build-wrapper” and use it as a prefix to the build command for your Microsoft Visual Studio project. As an example:
build-wrapper --out-dir [output directory] msbuild /t:rebuild
and just add a single property to configuration of analysis:
The build wrapper will eavesdrop on the build to gather configuration data, and during analysis the plugin will use the collected configuration without the headaches of manual intervention. Moreover, this works perfectly for projects that have mixed subcomponents written with different dialects.
So all this means that from now you can easily add projects written using C++/CLI and C++/CX into your portfolio of projects regularly analysed by SonarQube.
Of course, it’s important that the growth of supported dialects is balanced with other improvements, and that’s certainly the case in this version: we made several improvements, added few rules and fixed 28 bugs. And we’re planning to go even further in the next version. Of course, as usual there will be new rules, and improvements, but we’ll also be adding a major new feature which will make analysis vastly more powerful, so stay tuned.
In the meantime, the improvements in version 3.2 are compatible with all SonarQube versions from 3.7.4 forward, and they’re worth adopting today.
In this episode of The Weekenders, Tito spends the weekend trying to organize his friends to follow his agenda, with disappointing results. Frustrated, he comes home for dinner…
Tino’s Mom: You know, a kite flies on a string, not a stick.
Tino: [pause] Wow! I could see your lips moving, but it was like you were just going “blah, blah-blah”.
Sometimes, organizational change conversations feel like this.
Do you know about the Conscious Software Development Telesummit? Michael Smith is interviewing more than 20 experts about all aspects of software development, project management, and project portfolio management. He’s releasing the interviews in chunks, so you can listen and not lose work time. Isn’t that smart of him?
If you haven’t signed up yet, do it now. You get access to all of the interviews, recordings, and transcripts for all the speakers. That’s the Conscious Software Development Telesummit. Because you should make conscious decisions about what to do for your software projects.
Lean Startup in the Wild Meet Scoo ( just one of her many names ). Scoo is approximately 3 years old, a lover of bags, owner of all things with string, hedonistic, energetic, a tyrant to her older siblings, and famous for her contrarian attitude. Scoo, I was to come to fully realize somewhat later, is […]
The post Lean Startup in the Wild – Lessons From a Picky Customer appeared first on BigVisible Solutions.
Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally. In some cases, management may even be hostile to the concepts and practices of Agile methods. If you are interested in Agile, you don’t have to give up hope (or look to switch jobs). Instead, here are some tips to start using Agile methods even in hostile environments.
Some Agilists claim that the retrospective is actually the key to being Agile. In some ways, this is also the easiest practice to introduce into an organization. Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“. These are retrospectives that can be done in 15 minutes or half an hour. Try to do them with your team weekly. If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting. If you are “just” a team member, you might have to get some modest amount of permission.
So why would it be good to do a retrospective? Because it’s a high return-on-investment activity. For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning. Here are a couple more articles about the importance of retrospectives:
Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start. Myself, my first formal Agile environment, I started with the Daily Scrum. Another time less formal, I started with Test-Driven Development. In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months. This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders. This is the practice-by-practice approach. Start with a simple Agile practice that you can do without asking anyone for permission. Make sure it is a practice that makes sense for your particular environment – it must produce some benefit! If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start. If you are more business-oriented, then maybe consider user stories or one of the Innovation Games. If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.
It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another. If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.
Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy. This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”. This is an opportunity to do Agile. Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.” There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support. In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it. Don’t talk about it.
The “just do it” approach requires that you have some influence. You don’t have to be an influencer, but you need connections and you need charisma and you need courage. If you don’t have at least two of those three, you shouldn’t try this approach. You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works. Here are a few comments on Stealth Methodology Adoption.
There’s nothing like working with a band of rebels! If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work. Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans. Of course, you need to actually execute some of your plans. Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.
But, like any rebellion, you really need to trust those you work with in these early stages. Lacking that trust will slow everything you do possibly to the point of ineffectualness. Trust means that you have, for some time, a formal vow of silence. Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.
Read “Fearless Change”
I can’t recommend this one enough! Read “Fearless Change” by Mary Lynn Manns and Linda Rising. This is a “patterns” book. It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use. Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent. Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.
Don’t Call it “Agile”
This isn’t really a “tip” in the sense of an action item. Instead, this is a preventative measure… to prevent negative reactions to your proposals for change. The words “Agile” or “Scrum”, while they have their supporters, also have detractors. To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names. Use another name. Or let your ideas go nameless. This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”. By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.
A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”. Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.
Get Some Training
Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program. It’s a 40-week program that takes about 12 hours/week of your time for coursework. The next cohort of participants starts in June 2015 and we are taking deposits for participants. This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
This month Karen and I were lucky enough to have 2 unplanned sessions with a group of other coaches. It was so great to talk to fellow coaches about what’s working, what isn’t, to hear their war stories, get their advise, and to share our stories. We feel we benefitted greatly from these conversations, so our monthly retrospective action was to come up with 3 ideas to connect with other coaches. Here are our thoughts.
For a group of 3-5 coaches to sign up for a 2 month experiment. Each person will coach another person for an hour every 2 weeks. The coaches might be international – so you would need to figure out a time that suits you and the other coach.
You will get a personal coaching session every 2 weeks.
You will give (another) coach a personal coaching session every 2 weeks.
After 2 months (roughly 4 sessions) we will all reflect and see if this worked or not.
To have a local meetup for coaches to attend. You need to be a coach to attend. Perhaps we can borrow the Lean Coffee approach for this.
To create an online call for 3-5 coaches to attend every 2 weeks for around 90 minutes. The time will depend on the attendees – could be international. Each coach gets a turn to facilitate the group session.
We run it for 4 sessions and then reflect in the 5th how it worked.
For each of these ideas the attendees need to come prepared to give and to get. It will need to be a safe and trusted environment. There should be no money exchange happening. We give our services freely and expect the same from others.
Do any of these sound like a winner to you? Which would you be interested in?
We would like to start these in mid January – so if you are keen – please drop us an email or leave a comment below. Let us know which idea you like the best – or if you have another idea!
The full potential of many an agile organization is hardly ever reached. Many teams find themselves redefining user stories although they have been committed to as part of the sprint. The ‘ready phase’, meant to get user stories clear and sufficiently detailed so they can be implemented, is missed. How will each user story result in high quality features that deliver business value? The ‘Definition of Ready’ is lacking one important entry: “Automated tests are available.” Ensuring to have testable and hence automated acceptance criteria before committing to user stories in a sprint, allows you to retain focus during the sprint. We define this as: Ready, Test, Go!
Behaviour-Driven Development has proven to be a fine technique to write automated acceptance criteria. Using the Gherkin format (given, when, then), examples can be specified that need to be supported by the system once the user story is completed. When a sufficiently detailed list of examples is available, all Scrum stakeholders agree with the specification. Common understanding is achieved that when the story is implemented, we are one step closer to building the right thing.
The specification itself becomes executable: at any moment in time, the gap between the desired and implemented functionality becomes visible. In other words, this automated acceptance test should be run continuously. First time, it happily fails. Next, implementation can start. This, following Test-Driven Development principles, starts with writing (also failing) unit tests. Then, development of the production code starts. When the unit tests are passing and acceptance tests for a story are passing, other user stories can be picked up; stories of which the tests happily fail. Tests thus act as a safeguard to continuously verify that the team is building the thing right. Later, the automated tests (acceptance tests and unit tests) serve as a safety net for regression testing during subsequent sprints.
That's simple: release your software to production. Ensure that other testing activities (performance tests, chain tests, etc) are as much as possible automated and performed as part of the sprint.
The (Agile) Test Automation Engineer
In order to facilitate or boost this way of working, the role of the test automation engineer is key. The test automation engineer is defining the test architecture and facilitating the necessary infrastructure needed to run tests often and fast. He is interacting with developers to co-develop fixtures, to understand how the production code is built, and to decide upon the structure and granularity of the test code.
Apart from their valuable and unique analytical skills, relevant testers grow their technical skills. If it cannot be automated, it cannot be checked, so one might question whether the user story is ready to be committed to in a sprint. The test automation engineer helps the Scrum teams to identify when they are ‘ready to test’ and urges the product owner and business to specify requirements – at least for the next sprint ahead.
So: ready, test, go!!
I can’t shake off the impression that being a manager and guilt somehow goes hand in hand. It seems like managers cannot have a peace of mind for a few minutes, especially in the current online world. A manager is online 24/7, on her laptop, blackberry, smartphone. The work follows her like a shadow (which the online world basically is). But instead of embracing this digital world, managers tend to dislike it. In my opinion, the reason for that is that managers still have the illusion of a traditional work-life-balance. I have noticed that the traditional work-life-balance, in other words, 8 hour work day (Monday to Friday) does not exist.
The manager will always lose with the traditional 5 work day (38 hours/week) mindset. It seems like the manager cannot satisfy anybody, not even herself. Of course you can always work harder and much more, but the fact is not how much you work rather than how effectively you use your time. The reality is that you cannot work on three projects at the same time. You cannot persuade yourself by thinking three hours of sleep every night is fine. These habits will lead to a self-destructing life sooner or later. If you want to be effective as a manager then you have to commit yourself on one task at a time. You are asking why?
Pretty simple: sleep deprived people are not good at rational decision making nor are they awake enough for decoding the gut feeling which helps to make the right decision. (There is a reason why studies found out that a person with 24 hours sleep deprivation drives as a good as someone who is drunk). Hence, people who lack a lot of sleep are basically useless.
So what could be the solution to this problem? You could quit your job and start growing vegetables in your garden or just make a few changes to your lifestyle. For example, I have found these solutions working for me:
- I sleep 8 hours a day (here are 10 reasons why) and that means I am not reachable except when someone is calling my emergency number.
- I stopped doing several things at a time, instead I do only one task at a time – multitasking is a myth, which simply does not work (if you do not believe me look at this interview with Stanford professor Clifford Nass).
- As a Scrum Consultant I have learned to commit myself to the one thing at a time. In other words to my sprint planning and daily tasks, which leads to a focused and better outcome.
My main responsibility as a ScrumMaster is to enhance efficiency, and a burned-out Manager would stop the productivity completely. As a ScrumMaster you have to act as a manager, shrink, developer, doctor, engineer, etc. I call it a 360° versatile role. So this goes out to the managers who understand where I am coming from. Just try this for a month and tell me about your experiences.
Over the weekend, I attended and spoke at the Nodevember conference in Nashville, TN. At this conference, I spoke on the subject of destroying your IDE in favor of using smaller, light-weight, flexible and composable tooling like Grunt, Grunt-Contrib-Watch and others. I had a strongly positive amount of feedback from the session, which is always nice, and I felt like it went well.
If you’d like to get my slides (PDF and Keynote), you can do so at my Github repository for the presentation.
If you weren’t there, or even if you were and you want to watch it again, the amazing crew from Nodevember ensured that all talks were recorded and made available free of charge on YouTube. You can watch the video directly on YouTube, or here in the blog post:
One of the ironies of being a technologist in the Agile world is that while we love our tools and toys, we also know that some things should be done by hand. One of my jobs as a consultant at VersionOne is to help people understand what the tool will and won’t do. Needless to say, I believe wholeheartedly that the tool does all that it should, and is a fantastic tool for understanding where we are as a team, and where we intend to go. Its a very interesting balancing act, and I have always been impressed, especially when I was a customer, at how well the product management team performs this act.
I am often asked “when will you automate the workflow for a [epic/story/task/test]”? My answer has been the same for quite some time now: “hopefully never”. This gets me some interesting responses, mostly disbelief. The fact that the workflows are not predefined is not a missing feature, but a fundamental understanding of a basic fact. Automated workflows are inherently not Agile.
Let’s start with the most glaring evidence of this statement. The Agile Manifesto’s very first identified value is Individuals and Interactions over Processes and Tools. Tools are valuable when they enable interactions between individuals. When they start to replace those interactions, we are hurting ourselves. Agile is about being able to be quick on our feet and embrace change, even late in development. Having a tool enforce what should happen next slows that down. Let the tool represent what is going on, not try to decide what is going on.
The next challenge is the fact that Agile teams understand the pitfalls of Big Design Up Front. If we acknowledge that trying to create an entire design and architecture up front is a waste of time and energy, why don’t we acknowledge the same for designing a process up front? There are just too many different states that a story, etc. can be in during development to be able to predict the flow. Any attempt to do so is taking energy away from our primary purpose, which is providing value to our customers. Obviously we will have some agreements of general ideas, like Test comes first, and a story isn’t accepted until all of the tests pass, but we don’t need to automate that.
Lastly, let’s remember the main difference between Agile planning ideas and traditional planning ideas. The idea around Agile processes’ planning is to reflect and react to reality. VersionOne provides many ways to do this, my favorite being Team Rooms. I want a wall sized monitor where I can project my Team Room on the wall in my workshop, providing me with a giant informed work-space. Traditional processes try to bend reality to some arbitrarily decided workflow. And guess what? Whenever there is a battle between our planned workflow and reality, reality will always win.