The Product Backlog is often described as the primary input to Scrum. The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog. In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog. And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role. I believe in just starting if you can. I even wrote a blog post about this a while back and I stand by it.
I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing. Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start. And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.
The Scrum Guide recognizes the following inputs to Sprint Planning:
- Product Backlog
- Latest product increment (not applicable to first Sprint)
- Projected capacity of the Development Team during the Sprint
- Past performance of the Development Team (not applicable to first Sprint)
- Definition of “Done” (implicitly)
A newly-formed team often needs to address the following before the first Sprint:
- Product Backlog
- Projected capacity of the Development Team during the Sprint
- Definition of “Done”
If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).Product Backlog
Keep it simple. It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product. Get the Product Owner to blow these things out into a list. It doesn’t need to be a complete list. Just the most important things right now. A good test is to give the Product Owner 5 minutes. Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on. There are all kinds of techniques that can be used to order the Product Backlog. The simplest way is to just have the Product Owner eyeball it. If people are uncomfortable with this, then introduce the other ways. It doesn’t need to be perfect. It will get better and become refined and adapted as you go.Projected capacity of the Development Team during the Sprint
Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%). If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post. According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).Definition of “Done”
This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done. The team needs to know this before it can estimate the items in the Product Backlog as a team. Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.Planning with the Product Backlog, projected capacity and Definition of “Done”
In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”. Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done. All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built. The team should try to create a set of tasks each of which are a one-person day effort or less. Count the number of tasks. If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog. If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.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!
A few weeks ago I gave a talk at NSBCon NYC on scaling NServiceBus, and one of the pieces I highlighted were various saga/processing patterns and how they can affect performance. It was difficult to give real numbers as part of the discussion, mostly because how long it takes to do something is highly variable in the work being done and environmental constraints.
I compared three styles of performing a set of distributed work:
And highlighted the performance differences between them all. Andreas from the Particular team mentioned that some work had been done to improve saga performance, so I wanted to revisit my assumptions to see if the performance numbers still hold.
I wanted to look at a lot of messages – say, 10K, and measure two things:
- How long it took for an individual item to complete
- How long it took for the entire set of work to complete
Based on this, I built a prototype that consisted of a process of 4 distinct steps, and each variation of process control to track/control/observe progress. You can find the entire set of code on my GitHub.
Here’s what I found:Process Total Time Average Median Observer 6:28 0.1 sec <0.1 sec Controller 6:25 3:25 3:37 Routing Slip 2:57 2.6 sec <0.1 sec
Both the observer and controller styles took roughly the same total amount of time. This is mostly because they have to process the same total amount of messages. The observer took slightly longer in my tests, because the observer is more likely to get exceptions for trying to start the same saga twice. But once an item began in the observer, it finished very quickly.
On the controller side, because all messages get funneled to the same queue, adding more messages meant that each individual item of work would have to wait for all previous items to complete.
Finally, the routing slip took less than half the time, with higher total average but comparable median to the observer. On the routing slip side, what I found was that the process sped up over time as the individual steps “caught up” with the rate of incoming messages to start the process.
This was all on a single laptop, so no network hops needed to be made. In practice, we found that each additional network hop from a new message or a DB call for the saga entity added latency to the overall process. By eliminating network hops and optimizing the total flow, we’ve seen in production total processing times decrease by an order of magnitude based on the deployment topology.
This may not matter for small numbers of messages, but for many of my systems, we’ll have 100s of thousands to millions of messages dropped on our lap, all at once, every day. When you have this situation, more efficient processing patterns can alleviate pressure in completing the work to be processed.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
Sometimes, you just need to get on with the work. You need to give yourself some breathing room so you can think for a while. Here are some tips that will help you tackle the day-to-day management work:
- Schedule and conduct your one-on-ones. Being a manager means you make room for the people stuff: the one-on-ones, the coaching and feedback or the meta-coaching or the meta-feedback that you offer in the one-on-ones. Those actions are tactical and if you don’t do them, they become strategic.
- As a manager, make sure you have team meetings. No, not serial status meetings. Never those. Problem solving meetings, please. The more managers you manage, the more critical this step is. If you miss these meetings, people notice. They wonder what’s wrong with you and they make up stories. While the stories might be interesting, you do not want people making stories up about what is wrong with you or your management, do you?
- Stop multitasking and delegate. Your people are way more capable than you think they are. Stop trying to do it all. Stop trying to do technical work if you are a manager. Take pride in your management work and do the management work.
- Stop estimating on behalf of your people. This is especially true for agile teams. If you don’t like the estimate, ask them why they think it will take that long, and then work with them on removing obstacles.
- If you have leftover time, it’s time to work on the strategic work. What is the most important work you and your team can do? What is your number one project? What work should you not be doing? This is project portfolio management. You might find it difficult to make these decisions. But the more you make these decisions, the better it is for you and your group.
Okay, there are your five tips. Happy management.
Just a quick note today to let you know that the Call for Sessions for ScanAgile, the Agile Finland annual conference is open for submissions.
You can read the whole call for sessions here. You will find the submission form in that page as well.
For me the most interesting tracks are:
- Off-Piste: interesting lessons learned about being agile and agile related topics, from other industries
- Black Piste: Topics for experienced agile practitioners
The Agile Finland Community is very active and has a long history of agile adoption and promotion. They have some of the most advanced practitioners in the world, so I am really looking forward to see who the Scan Agile team chooses for the 2015 lineup of the conference!
Hope to see many of you there!
In my previous post Agile Assessments, I wrote about reasons to do an assessment and considerations when doing one. In this post, I’ll continue the assessment topic with focus on Rating Scales and Frequency.Select a Rating Scale
When conducting an agile assessment or self-assessment, an understandable rating scale should be used that allows the rater to assign a value to the practice or capability being rated.
A Scale of 1 to n is so common it has become part of our vocabulary and for good reason: It’s easy to understand and very straightforward.
Including a qualitative description of each number in the scale will improve the usefulness of the rating scale. For example, if a rating of 2 is described as “Apprentice” or “Beginner”, the category is more likely to mean the same thing to different people. And if we expand the definition further, the raters are even more likely to apply the rating similarly. Let’s look at this further in the following example:Numeric Only Numeric + Minor Qualification Numeric + Detailed Qualification 0 0 – Not started 0 – Not started – The practice/capability is not yet understood and/or is not yet in use by the team 1 1 – Apprentice 1 – Apprentice – Beginning to learn and apply practice/capability. Guidance from experts is recommended. 2 2 – Journeyman 2 – Journeyman – Practice/capability is well understood and is sustainable by the team. 3 3 – Expert 3 – Expert – Practice/capability is fully internalized. Team can teach and mentor others.
Each level of qualification brings more clarification and shared understanding of the numeric rating. Keep this in mind when you select a scale and include a description for each that will help the raters apply the scale with some degree of consistency. Consistency in the interpretation of the rating scale will be important to a team as they continue to self-assess periodically. It is also important for the organization when measuring progress across teams to get an overall view of an agile transformation.
Using Colors and Symbols
Graphic/visual representations, in addition to or instead of a numeric scale, can bring life to the assessment process and quick interpretation of the assessment results, particularly if you have an open work space to display them. Standard traffic light colors, plus black, offer a simple translation:
◉ Black – Not Started
◉ Red – Practice/capability has started but needs significant improvement
◉ Yellow – We are practicing the competency consistently
◉ Green – Team has fully embraced practice/capability and internalized it into culture
You often see the use of four/five stars in online ratings of movies, books and restaurants and we all understand that a ‘5 star hotel’ is very luxurious and comes with many amenities. Our assessment star rating scale would look something like this:
★★★★★ – Not started
★★★★★ – Just beginning use of practice/capability
★★★★★ – Practice/capability is understood but not used consistently
★★★★★ – Practice/capability is used most of the time
★★★★★ – Demonstrable evidence practice/capability has been mastered
★★★★★ – Teaching and mentoring others on practice/capability
Like the traffic light colors, it’s a visual rating that we’re used to seeing and doesn’t require a lot of thought to interpret. The stars really do represent numbers though and you can choose to use them mathematically and roll up scores to a major category level or overall assessment score.
My preference when conducting an assessment for an organization where I am the rater is to use a numeric scale that includes a clear and detailed qualitative description. This helps me take more time to consider the criteria and the circumstances. When guiding a team on their self-assessment, I’ve observed that the use of the graphic/visual format takes away the reluctance some individuals have when choosing a number, allows the process to go faster and achieves a result closer to reality. Personally, I find that I can over think numbers but don’t second guess so much when selecting the color Yellow or 4 Stars. You may not find this true if you’re not a visual thinker.How Often Should You Reassess?
If you look back at some of the reasons to do an assessment from my Agile Assessments post, many of them set the expectation that it’s a recurring activity. A few from the list include: “Establish Baseline”, “See how you’re tracking against your transformation goals”, and “Determine if you’re ready to move to next level”. While ideally you’re already using metrics to improve your processes in general, an agile assessment or assessment instrument has a more specific purpose and lifespan in support of an agile transformation. Once a team and/or organization reaches a greater level of maturity in their adoption and agile becomes ’the way you build software”, the assessment instrument will largely cease to provide value. It doesn’t mean you stop continuously improving but we have the retrospective for that.
The frequency of the assessment should take into consideration the rate of change you’re expecting between assessments. For example, if I assess a new team, send them to training and leave them mostly alone to figure it out, I’m not going to anticipate a great deal of improvement in the next 30 days and therefore, I may wait a couple months to re-assess. Contrast that with a team who is given training, has a scrum master or other leader on the team with agile experience, and they also have continued and focused coaching. I would expect to see change in a months time and will want to have visibility to the progress via the assessment results. Every few sprints is a good, general guideline when you’re getting started. Once you set the interval, stick to it.
Most important to me is that someone is using the assessment results for a clear purpose. I’ve seen teams complete their self-assessment on a regular cadence because the organization required them to but do absolutely nothing with it. I know the company was truly interested in understanding how their transformation was progressing and to know where support was needed for the team but the assessment results weren’t being used to understand progress or areas for improvement. If the results aren’t being used or understood, it might be time to step back and re-evaluate.On to Methods and Results
You can look forward to my next post where I’ll share a few different approaches for administering an assessment and how to report your results.
Experience with Sinatra, and some thinking, has caused us to look at a shift in approach. Martin Fowler was probably right.
Early in this project, Martin wrote to me, asking “why dynamic” and offering his bliki software for my use. My answers were that to get my hands dirty, I really wanted to do it myself, and that I chose dynamic solely on the principle of late binding. I’ve somewhat come to my senses.
I am a very old person, which I hope is not in any way noticeable, despite my desire that you all keep off my lawn. I came to realize that while I hope I’ll be writing and drawing stupid pictures for a long time, I will probably not be wanting to fiddle with configuring Ruby/Sinatra/Kramdown/etc on my web site for very long at all. In fact, I already don’t want to do that. I also don’t want to maintain the WordPress stuff that is there now, especially since my webmistress (not as interesting as it sounds) is leaving the area.
Therefore, I decided that I wanted a static site. Some software now, to generate it, but push come to shove you can push new articles up with FTP or similar tools, so it will be relatively maintainable ad infinitum.
(I freely grant that I could be entirely wrong about all this. Nonetheless, static is hopefully here to stay.)
So, a bit of looking and we’ve settled on Jekyll as a basis for the site. In second place, Middleman, which I rejected on the basis of its (non-) documentation. In third place, just code it up. Code it up is running strongly and could catch the leaders.Starting on ronjeffries.com
Happens I own ronjeffries.com. (No, don’t bother to buy up all the other ronjeffries.etc, and sell them to me at a profit. Dot com will do me just fine.)
So the current plan is to build up ronjeffries.com incrementally. We’ll deploy it as soon as my host can get it set up. He’s a bit overwhelmed with personal matters just now but I want to stick with him.
The site wants to integrate XProgramming, new material, maybe even my tumblr. So it needs to be able to support something not unlike the current organization. All the articles (at least the ones I decide to keep), and a bit of organization, done with categories in WP.However …
Jekyll doesn’t quite want to do all that, at least not at first glance. Let’s revisit the requirements.
My existing site has the notion of general articles and three special kinds: Kate, Beyond, and Classic. The front page shows the most recent Beyond, the most recent Kate, a random Classic, and then, after that row, the five or six most recent other articles. I think I’ve mentioned in previous articles that those groupings may not be quite right, but the basic idea applies.
Jekyll, it seems, is “blog aware”. What that means in practice seems to be that much of its capability revolves around having a list of posts named 2014-10-11-foobar, and laying them out in a typical blog style. Next/prev, dated indexes, and the like. All very well and good but not quite what I’m about.
I write a bunch of articles about generally Agile topics. Those ought to be some kind of category, perhaps the Beyond heading, perhaps not. There might be threads. I write series of coding things like the recent ones with Codea. These generally don’t go anywhere, they just display how I’m approaching developing something over the period where I play with things. (I should probably say at the beginning of each of those that it will not have a nice live happy ever after ending, because when I get bored with that tool or topic, I’ll stop.)
I write Kate Oneal stories. I write other themed things.
Each of these needs an index page, and some of the lists are long and courtesy suggests the index should be paged.
And I have a writing requirement, or at least writing desire, which is to put each article and its associated pictures in its own folder. This makes writing easier (currently using Sublime Text and Marked) because I can view what it looks like as I go, and can push it up without worrying about name overlap in an images folder.
I plan to have the article “slug” (which I guess means web-compatible name) be the name of the folder, and in a great concession, I am prepared to name all the articles index.markdown, each in its own folder. I’d rather give them a meaningful name but at least right now I’m not seeing quite how to make that happen in Jekyll.
And I really don’t want to call them all 2014-10-11-whatever, though perhaps I need to get over it.What’s there and what’s apparently not
It’s early days with Jekyll, we just talked about it via email a tiny bit last week, read some stuff, and I tried some things yesterday. Here’s what I think I have learned.
Jekyll will scan your whole input folder structure and process files you tell it to, and will process any file that starts with some YAML. It digs down through nested folders at least as well as I need it to.
But inside the standard _posts folder, it will only process files with the date prefix format, as far as I can tell. That is, a file containing YAML but not named by the date standard, gets ignored entirely. It’s not even copied over raw. In other folders, Jekyll processes the text files and copies others such as images. So inside posts, I’d be stuck with the dated names. I really don’t want to go there.
In other folders than _posts, it processes most everything, so I can put all my articles under, say “Articles” and they’ll all get run through kramdown and rendered to html. They can have categories, and other goodies in the YAML, so maybe a flat structure would be enough.
And there are “collections” in Jekyll. They are red-flagged with markers saying they might change. What seems to maybe happen (based on a limited experiment) is that you can name a collection in your config, then have a folder of that name, and everything inside it goes into the collection. Then you can process that collection in your templates and includes.Where are we?
We’re in very early days in Jekyll, just finding our way. Today will be our first day pairing with it. Should we just use categories or the like to sort out the Kates from the Beyonds? Should we use collections?
We’re not sure. I’ll report more when I know more. Meanwhile, if you know stuff I should know about Jekyll, please drop me an email. Thanks!
An der Generation Y wird gerade wieder diskutiert, was die Wahlfreiheit mit uns macht. Einerseits wollen wir sie nicht mehr missen und anderseits gehen wir unter ihr in die Knie. Hier ein Beispiel:
Es gab mal eine Studie, bei der den Probanden auf der Straße ein Eis geschenkt wurde.
- 1. Set up
Die Probanden haben 3 Sorten Eis zur Auswahl: Vanille, Schokolade und Erdbeer. Jeder bekommt genau eine Kugel Eis. Anschließend werden sie befragt, wie zufrieden sie mit ihrer Wahl sind. Ergebnis: Sie sind durch die Bank glücklich, ein Eis geschenkt bekommen zu haben und froh über die Wahl, die sie getroffen haben.
- 2. Set up
Die Probanden haben 10 Sorten Eis zur Auswahl: Stracciatella, Limone und was man sich noch so denken kann. Jeder bekommt wieder genau eine Kugel Eis. Die Antworten bei der anschließenden Zufriedenheitsbefragung fallen diesmal allerdings ganz anders aus. Die Mehrheit der Befragten ist weit entfernt von Zufriedenheit. Die Tatsache, dass sie gerade etwas geschenkt bekommen haben, schwindet aus der Wahrnehmung. Kennzeichnend für die Stimmung der Leute ist allein das Gefühl, die falsche Wahl getroffen zu haben: Eine der anderen Sorten wäre bestimmt leckerer gewesen.
Es kommt darauf an
Zunächst einmal hängt das davon ab, welcher Typ ich bin.
Persönlichkeitsprofil-Modelle wie das MBTI, oder die Lehre von Motivationsprofilen, besagen, dass es Menschen gibt, die durch permanente Wahlmöglichkeiten motiviert sind und sich wohler fühlen je mehr Optionen zur Auswahl stehen. Und andere Typen halten es in undefinierten Situationen schwer aus und sind bestrebt, die Türen schnell wieder zu schließen, einen Haken dran zu machen. Lieber irgendeine Entscheidung als keine.
Und dann hängt es von meiner Kompetenz ab, mit Wahlfreiheit umzugehen.
Schauen wir uns an, welche Antworten das Scrum-Universum auf dieses Dilemma hat.
In Scrum hat alles seine Zeit. Türen öffnen hat seine Zeit und Türen schließen hat seine Zeit.
Beim Review, bei der Retrospektive und beim Backlog-Grooming mache ich den Raum auf für neue Ideen und Möglichkeiten. Bei den Sprint Plannings schließe ich die Tür wieder, indem ich mich entscheide, was ich in den nächsten zwei Wochen machen will. Und im Sprint drehe ich den Schlüssel vom Sicherheitsschloss zweimal rum. Jetzt gehe ich mit meiner Entscheidung und verwandle sie in eine Erfahrung. Am Ende der zwei Wochen weiß ich, ob das eine gute Entscheidung war.
Was kann die Generation Y daraus lernen?
Für Antworten brauche ich Erfahrungen*. Ohne Entscheidung kann ich keine Erfahrung machen. Und ohne Erfahrung gibt es keine Kurskorrektur.
Ich schließe mit einer kleinen Geschichte.
Ein Bauer kommt zum weisen König und fragt ihn, ob er ihm erklären kann, was Freiheit ist. Der König fragt den Bauern: “Kannst Du ein Bein heben?”
“Ja”, sagt der Bauer.
“Gut, welches Bein willst Du heben?”
Der Bauer überlegt kurz und sagt dann: “Das linke.”
“Gut”, sagt der König, “dann hebe Dein linkes Bein.”
Der Bauer hebt darauf sein linkes Bein.
“Jetzt heb Dein rechtes Bein”, sagt der König daraufhin zum Bauern.
Der Bauer schaut ihn verdutzt an und sagt: “Aber das kann ich nicht.”
“Siehst Du”, sagt der König, “jetzt weißt Du, was Wahlfreiheit ist.”
In diesem Sinne, viel Spaß beim Entscheiden.
*”Und Dich hat man wieder mal ausgelacht, weil Du für Antworten Erfahrungen brauchst” – aus dem Lied //www.youtube.com/watch?v=z73vzMfWgMs
Erfahrungen” von Felix Meyer
He began the talk with his experience coming out of college with an engineering degree. He found the math and science classes did little to prepare him for the real world, the people part of the equation, or the “all important last 99%” of being successful. It’s the soft skills that are hard, the people and relationship skills but that’s not what is the focus of education.
He then went on to talk about the Agile Manifesto and how that is the key to successful project management. From here, he shared some other pieces of wisdom
- Politics is life, relish it. If you don’t like politics, you probably shouldn’t be managing projects
- While intelligence (IQ) is important, having good emotional intelligence (EQ) is more important
- Whoever tries the most stuff wins. Again, sounds like the idea popular in agile circles about failing fast.
- To be effective, you need to “suck down” and help the people on your team. He didn’t use the phrase “servant leadership” but that’s what it sounded like to me.
- There’s no excuse for a poorly run meeting. Take the time to prepare so that it is effective. We can’t get rid of meetings.
I’m always pleased to see bright people explaining and summarizing SAFe better than I can. In a recent post, Eric Willeke, a leader in the kanban community, describes how SAFe handles WIP limits at the portfolio level (after all, if you don’t limit the really big WIP there, the rest of the system may be in deep trouble, no matter what else you do). He also points out the connection between Portfolio WIP management and Lean Agile Budgeting, which is a critical, though subtle, connection that helps achieve flow.
here is the post: http://ericwilleke.com/posts/safe-portfolio-limits/
and here is an excerpt/teaser:
by Eric Willeke.
Portfolio Distribution: SAFe significantly simplifies the decisionmaking around the above concerns through the recommended budgeting approach, which explicit allocates both budget, delegated financial authority, and scope determination to the release trains as the default approach. This leads to a significantly reduced portion of the overall spend being managed as explicit items in the portfolio flow, Instead, the majority of the work can flow “horizontally” at the train level without incurring the administrative and governance overhead associated with the larger items flowing through the portfolio backlog. The portfolio flow is intended to be used only for those items that cut across trains and are of sufficient size that they need explicit financial governance. Reference. SAFe additionally provides an optional value-stream level coordination layer to manage coordination of those cross-cutting items that demand additional coordination due to the various dependencies that remain after making the organizational structure trade-off decisions without adding the additional financial governance overhead.
I once worked in a team with an amazing developer, let’s call him Henry (not his real name). Henry refused to play the Tech Lead, preferring to stay as hands-on with code as much as possible. When the team had a technical problem, they would first go to Henry. He always offered a well-balanced opinion on technical decisions which meant the team almost always agreed with his proposals. Even business people recognised his technical aptitude. When he asked for time to work on important technical tasks, he always got it.
Although Henry was just a “Developer”, he lead the team in a number of ways.Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence You don’t need to be a “Lead”
My experience with Henry showed me how you do not need a title with “Lead” to demonstrate leadership. Conversely, having a title with “Lead” doesn’t suddenly bestow someone with leadership skills.
A developer who cleans up some messy code without being asked demonstrates initiative. The tester who brings the developer and Product Manager to the same understanding demonstrates facilitation skills and these play a part of leading people. In this situation, it means:
Thinking and doing something for the benefit of the team without being told to do so.
There are, of course, many other attributes to being a leader, but that is a separate post.A Lead without leadership
You have probably worked with one of these people. A leader who tells people what to do, berates their team members for stepping slightly out of their role, even when the result is beneficial for everyone. They often have the need to supervise the smallest task and always want a say in every decision. These people are nothing other than micromanagers and demonstrate no leadership skills whatsoever.Great leaders encourage leadership
Unlike micromanagers, a real Lead focuses on creating an environment that allows everyone to demonstrate leadership. In chaotic situations, this may require more directive action with the goal of moving the team beyond a period of chaos into a safer environment. In a safer environment, the Lead encourages team members to do what they think is right. The Lead takes on a more guiding role and allows everyone to demonstrate leadership skills.Action is not the same as a title
Henry the developer demonstrated that people can take on responsibilities without officially playing a certain role. He also reminded me that titles, certifications and labels do not automatically guarantee competence. If you truly want to lead, you can.
If you liked this article exploring leadership, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
The featured image is shared from Flickr under the Creative Commons licence.
About a third of the way through Mastering Data Modeling the authors describe common data modelling mistakes and one in particular resonated with me – ‘Thin LDS, Lost Users‘.
LDS stands for ‘Logical Data Structure’ which is a diagram depicting what kinds of data some person or group wants to remember. In other words, a tool to help derive the conceptual model for our domain.
They describe the problem that a thin model can cause as follows:
[...] within 30 minutes [of the modelling session] the users were lost…we determined that the model was too thin. That is, many entities had just identifying descriptors.
While this is syntactically okay, when we revisited those entities asking, What else is memorable here? the users had lots to say.
When there was flesh on the bones, the uncertainty abated and the session took a positive course.
I found myself making the same mistake a couple of weeks ago during a graph modelling session. I tend to spend the majority of the time focused on the relationships between the bits of data and treat the meta data or attributes almost as an after thought.
The nice thing about the graph model is that it encourages an iterative approach so I was quickly able to bring the model to life and the domain experts back onside.
We can see a simple example of adding flesh to a model with a subset of the movies graph.
We might start out with the model on the right hand side which just describes the structure of the graph but doesn’t give us very much information about the entities.
I tend to sketch out the structure of all the data before adding any attributes but I think some people find it easier to follow if you add at least some flesh before moving on to the next part of the model.
In our next iteration of the movie graph we can add attributes to the actor and movie:
We can then go on to evolve the model further but the lesson for me is value the attributes more, it’s not all about the structure.
Karl Bredemeyer hat in seinem Artikel “Scrum in der Medizintechnik” die allgemeinen Vorteile agiler Methoden für die Entwicklung medizintechnischer Produkte beschrieben. Durch einen iterativen und inkrementellen Ansatz sind Verifikation und Validierung durch die gesamte Entwicklung hindurch möglich. In diesem und den nächsten beiden Beiträgen zeigen wir anhand von konkreten Beispielen aus unseren Projekten, wie das geht.
Anders als bei reinen Softwarelösungen sind bei medizintechnischen Produkten in der Regel verschiedene Komponenten – Mechanik, Eletronik, Software – miteinander zu integrieren, um ein Produktinkrement zu erreichen. Nehmen wir ein Beispiel:
Bei einem Gerät zur Laborautomatisierung soll ein Schließmechanismus für Röhrchen gebaut werden – dies ist unser Produkinkrement. Die Mechanik wird sich um Greifarme und Achsen kümmern müssen, die Elektronik um Motorsteuerung und Fahrmethode, und die Software um die Koordination der Arbeitsabläufe. Die Integration aller Komponenten zu einem funktionierenden Mechanismus mit wirtschaftlichem Wert kann nur dann gelingen, wenn zu jedem Zeitpunkt spezifiziert ist, wie sich das Gesamtsystem zu verhalten hat. Ausgangslage dafür sind in Scrum so genannte Epics. Sie postulieren, welche Funktionalität ein Benutzer des Systems braucht, und welchen Nutzen er davon hat.
Beispiel: Als Medizinisch Technische Assistentin (MTA) brauche ich einen automatischen Schließmechanismus für Röhrchen, damit ich die Laborproben nicht mehr von Hand verschließen muss.
In der Regel gibt es mehr als eine Epic pro Produkt. Neben dem Schließmechanismus könnten beispielsweise Öffnungsmechanismus, Transportmodul, Aliquotierfunktion sowie Ein- und Aussortierer dazukommen. Die Auflistung aller Epics in einer nach wirtschaftlichem Wert priorisierten Liste bildet das Product Backlog.
Im nächsten Schritt werden die Epics in Anforderungen, Akzeptanzkriterien und -tests sowie in Rahmenbedingungen analysiert. Das kann dann für die Epic aus unserem Beispiel folgendermaßen aussehen:
Anforderungen: Die Röhrchen sollen durch automatisches Aufdrücken einer Kappe verschlossen werden.
Akzeptanzkriterium:Der MTA muss keine zugelassenen Röhrchen mehr von Hand verschließen.
Akzeptanztest:600 Röhrchen mit zugelassenen Maßen werden innerhalb von 30 Minuten auslaufdicht verschlossen.
- Muss mit Röhrchen von 13-16 mm Durchmesser und 65-100 Millimeter Höhe funktionieren.
- Verschluss muss dicht sein.
- Kappe muss aus Polyethylen sein.
- Farbe der Kappe muss blau sein.
Ist eine Epic so heruntergebrochen, lässt sich bestimmen, welche Komponenten welchen Entwicklungsstand haben müssen, und welche Tests auf Komponenten- und Systemeben laufen müssen, um die Epic laut Akzeptanzkriterium zu erfüllen. Im hier genanten Beispiel werden Software, Elektronik und Mechanik so zusammenspielen müssen, dass Röhrchen zuverlässig versiegelt werden können. Ist dieses funktionale Zusammenspiel erreicht, ist das Produktinkrement erbracht.
Die Entwicklung orientiert sich an der sequenziellen Fertigstellung von Epics, die nach ihrer Priorität fertig gestellt werden. Somit ist zu jedem Zeitpunkt ein Produkt vorhanden, das potenziell (natürlich begrenzt auf die aktuell vorhandenen Funktionen) verwendbar ist. Weitere, nicht notwendige Funktionen (z.B. Zentrifugierung) können dann mit einem späteren Release ausgeliefert werden.
Im nächsten Beitrag erfahren Sie, wie Sie ein Entwicklungsteam zusammenstellen, das in der Lage ist, Produktinkremente zu liefern.
- Drei Argumente für Scrum in der Hardware
- Scrum History | Ken´s Talk über Qualität
- Wer hat Angst vorm ersten Wurf?
I am very pleased to announce that my “Agile Adoption Roadmap” Blog has just reached 100,000 hits. This is a great milestone and it makes me happy that there are so many professionals curious about Agile including many Agile enthusiasts, advocates, champions, coaches who are visiting and even commenting on my articles. It highlights that the many articles have value. If you want to receive its value, consider following this blog at: http://cmforagile.blogspot.com/.
To add to the statistics, I have folks from 45 different countries that have visited my site. The top 10 countries include: United States, United Kingdom, India, Russia, Germany, Canada, France, Australia, Ukraine, and China. Other countries that have significantly visited my site are: Sweden, Poland, Spain, Finland, South Africa, Iran, Norway, Iraq, Romania, Brazil, Argentina, Belarus, Malaysia, Portugal, Netherlands, Switzerland, and Italy.
The Agile Adoption Roadmap blog provides the reader with a range of topics related to adopting Agile within their teams and organizations. The content has a special emphasis on “being Agile” and bringing the Agile mindset to your work. I have written and posted 56 articles to date (although this one technically counts as the 57th). What are some of the top articles that Agile, IT, and Business Professionals have found of value? The top articles include:
- Who makes the best Scrum Master
- Agile Animal Farm – Pigs, Chickens, and more
- Agile Value Capture Metrics – Are you building value?
- Right-sizing Documentation in an Agile World
- Agile Definition of Done Starter Kit
- Agile – Its more disciplined than you think
- Gamification of your Agile Journey
- Agile Culture – Are you stepping up?
- The Role of Middle Management in an Agile World
- Are you Ready for your Agile Journey?
- Agile Executive Playbook
- Robust Agile Requirements – Its about the Discussion
- Is it finally time to “Be Agile”?
- Personas – Do you really know your Users?
- User Story Writing Starter Kit
- Agile Lagging to Leading Metric Path
Luis Gonçalves has posted a list of 100 Top Agile Blogs, ranked by Alexa ranking. I’m gratified to make the list, where I’m in some pretty good company.
Luis Goncalves has put together a list called the 100 Top Agile Blogs:
If you don't know Luis, he lives and breathes driving adoption of Agile practices.
Luis is also an Agile Coach, Co-Author, Speaker, and Blogger. He is also the co-founder of a MeetUp group called High Performing Teams, and he is a certified Scrum Master and Product Owner.
Here is a preview of the list of top 100 Agile Blogs:
For the rest of the list, check out 100 Top Agile Blogs.
Lists like these are a great way to discover blogs you may not be aware of.
While there will be a bunch of blogs you already know, chances are, with that many at a glance, there will be at least a few new ones you can add to your reading list.
Why is this?
Are the fringe areas more likely to be customer-focused?
For traditional enterprises, digital areas tend to be on the fringes and digital areas also tend to be significantly more customer-focused.
Peter Lee pointed out another possible explanation. In large enterprises, all the policies and processes will be designed for the core areas, not for the fringes. The fringe areas are already used to having to do their own thing, so Agile being different is not as big of a deal.
If this characterisation is true, does this suggest a path for successful Agile adoption?
- Start and establish on the fringes and ignore any focus on the core
- Get official endorsement (to protect gains)
- Core teams gradually adopt OR the fringes become dominant and slowly push out the old core
I’ll need to elaborate on this at some point, to share what I’ve experienced across lots of businesses large and small, as well as some of the biggest businesses on the planet, as they transform themselves for the digital economy.
Meanwhile, here is an interesting read on CIO Straight Talk magazine.
In their words, "CIO Straight Talk is a series of "straight talking" articles from senior IT executives and leading companies and government and nonprofit organizations."
This first edition is focused on learning, failing and learning in the Second Machine Age, and features two non-practitioner experts on current topics:
“Andrew McAfee, co-author of the New York Times bestseller The Second Machine Age, cofounder of MIT’s Initiative on the Digital Economy and Principal Research Scientist at MIT Sloan School of Management, talks about ‘The CIO’s role in the enterprise of the future.’ Says McAfee: ‘The overall trend is that companies of all stripes will need, proportionately, many fewer people in IT. Those who remain will be very highly valued, very highly skilled, very important… Enterprises are going to need someone to help them navigate the second machine age… I think that if the CIO plays her cards right, this can absolutely be her role in the enterprise.’”
Michelle Gallen, the CEO of Shhmooze, a social networking start-up, talks about failure, not to be confused Failure Lite – ‘I failed. How nice. I learned so much’ – often hailed breezily by management experts as something everyone should experience and every company should encourage. Real failure, according to this serial entrepreneur, isn’t pretty. Says Gallen: ‘I don’t think you learn without failing… In the start-up world, innovation is the ability to take an idea and turn it into an invoice. Lots of larger business organizations also rely on cash flow to keep them alive, and therefore innovation has to be monetized. If you’re Apple or Microsoft, you’ve got a war chest, and you can actually allow failure. A lot of companies can’t actually afford it. It’s quite an expensive hobby, failing.’”
So there you have it -- failure is an expensive hobby and the few IT leaders left in organizations will be very highly valued, very highly skilled, and very important.
There’s more to the story and I’ll share what I’ve learned over the past few years helping companies cross the Cloud chasm and accelerating their digital transformation.
I gave several training courses on being a Tech Lead and found myself giving a number of book recommendations. Although books are no substitute for experiential learning and close feedback cycles, they are useful as ways of introducing some key skills developers rarely practice in their day-to-day tasks.Negotiation
A Tech Lead represents both the technical perspective to outside stakeholders, and often carries a business perspective back into the technical team. Conflict is inevitable and understanding how to negotiate to an optimal solution for two parties is a timeless skill.
Getting to Yes was one of my favourite books. It’s short and insightful. The book describes the different between Positional-based negotiation (typical) vs Interest-based negotiation.
Meetings. Meetings. Meetings. Three dreaded words that a developer doesn’t want and often can avoid. A Tech Lead often dreads the numerous meetings as well, but will be often expected to contribute. Most meetings will be poorly planned and facilitated, leading to even more drawn-out meetings. In my experience, when done well, meetings can be focused, short and fruitful when they are well-facilitated. Facilitation skills are also useful on a day-to-day basis when ad hoc meetings between team members occur, or when a particular topic needs to be discussed.
The more collaborative a team becomes, the more useful facilitation skills are to the Tech Lead as they blur into the background to all voices be heard.
The Skilled Facilitator (Schwartz) is the first book I recommend to new facilitators. I find the book easy to read and is comprehensive in its explanation about the role of the facilitator.
Facilitator’s Guide to Participatory Decision-Making (Kaner) is a more focused book, covering how to have group discussions, balance hearing all views and to converge into the best outcome.
Collaboration Explained (Tabaka) is written by an agile practitioner who I trust dearly. I have see her facilitate, and her wisdom is captured in this book that will be highly relevant to particularly agile teams.
With authority comes responsibility and the Tech Lead suddenly sees risks everywhere. Or worse, they don’t see any risks at all.
Waltzing with Bears (De Marco and Lister) is the timeless book that talks about risk management in the settings of software development. Although some of the examples may feel a bit outdated (death march projects), our industry still has plenty of them and the lessons are still relevant for today’s style of software development.
Unsurprisingly the book recommendations above are not only relevant to Tech Leads, but to anyone who may find themselves in a leadership role. There are plenty more skills and books to recommend, but these are a good starting set.