Enjoy this excerpt from the latest Lean Business Report. Download the full report here.
If we were...
Let’s imagine a Scrum Master for a new team. The department has gone through a significant reorganization or new teams have just been created. These newly defined teams need to establish their Team Work Agreements, along with picking a name, getting a Team Backlog defined and so on. In other words: lots of activity for the new Scrum Masters! One area that tends to raise problems for new ScrumMasters and indeed the entire Scrum team is scheduling team meetings.
Setting up team meetings may seem like a simple thing but, it’s often more complex than expected. Concerns may include:
- When are all stakeholders available and must they be at all meetings?
- When does Sprint work end, before Sprint Review or can we work on things after that meeting?
- Do we have to wait for certain meetings to have work accepted?
- How many time zones are involved?
Without a place to start, figuring out the meeting schedule feels like too much at once. In this post, I’d like to give you a place to start.Common Patterns
Over my eight years as an Agile Coach, I have noticed patterns – common ways teams solve the meeting scheduling issue. Here are the three most common patterns that have worked for many of the teams I have had the privilege to coach. These recommendations are a good place to start. Mix and match elements to get an optimum schedule for you and your team.Pattern 1: Planning Day
There are three big meetings that mark the end and start of each Sprint: Sprint Review (Demo) and Sprint Retrospective (for the previous sprint) and Sprint Planning (for the upcoming sprint). In the common Planning Day pattern, all of these meetings are scheduled for the same day.The big attraction of this pattern is it takes just one day to get all the big meetings done. Get them done on the first day, start working the next day!
Because the Sprint Review and Retro meetings can be long and intensive, I often recommend the team break before starting Sprint Planning. This rest period (whether it’s lunch, a walk around the building or a chat with colleagues) allows team members to process the previous sprint and “freshen up” for the next one. Then the team begins Sprint Planning.
Note:Sprint Retrospective marks the end of the foregoing Sprint. Sprint Planning marks the start of the next Sprint. Sprint Review (Demo) marks the moment Sprint work time is over: User Stories are accepted before the Demo or are not done for that Sprint. Pattern 2: Planning Morning Pattern
Some teams like to have the morning to button things up and get ready for the Sprint Review (Demo). Then they end the day with their Sprint Retrospective, go home relaxed with the Sprint done. First thing the next morning, they do Sprint Planning and are off to work!
Note: Sprint Retrospective marks the end of the foregoing Sprint. Sprint Planning marks the start of the next Sprint. Sprint Review (Demo) marks the moment Sprint work time is over: User Stories are accepted before the Demo or are not done for that Sprint. Pattern 3: Time Zones Pattern
Some teams have members in distant time zones. Such teams need to adjust their schedules to match the most convenient overlapping hours for all the members. Often this means the meetings are all in the morning or all in the afternoon, depending where the team members reside. The sequence of the meetings might be less than ideal to accommodate the difficulty of the time zones.
In this pattern, I recommend that the Sprint Review be shifted one day forward to accommodate the need to have meetings always in one or the other half day. All work on User Stories would be completed before Sprint end on Monday morning in the schedule below, but the Retro would be held first thing Tuesday morning followed by Sprint Planning. This enables the team to get started work on User Stories for the next Sprint. Sprint Review would be held on Wednesday.
Note: Because of the need to have meetings in the mornings, Sprint Review (Demo) is shifted one day. All work on User Stories has been completed before the Sprint end. Demo what was completed by the Sprint end. Principles to Remember
Remember some principles involved here:
- As stated in the Agile Manifesto, Individuals and interactions over processes and tools – Schedule in a way that enhances the interactions of the team members.
- The Sprint Planning Meeting marks the start of the Sprint.
- The Sprint Retrospective marks the end of the Sprint. After the Retrospective, the Sprint is over. No adjustments to velocity, no working late to get something done, etc.
- The Sprint Review (Demo) shows only the work that was already accepted by the Product Owner before the meeting starts.
Within these principles, do what works for your team. And ask each other questions, share experiences and reach out to your train leaders and Agile Coaches to help get your meetings rolling. Let us know how you make planning meetings easier on everyone!
Docker + Node.js is a beautiful combination. But among all of the advantages of using these tools together, there are some mild frustrations… things that just don’t quite fit nicely.
Take the npm Wall of Red Text, for example.
It seems every time I run ‘npm install’ inside of my docker container, I nearly have a panic attack thinking my build is failing!
It’s nerve-racking to say the least… is my build failing? Did it fail? Or is this just the npm Wall of Red Text again?
9 out of 10 times, it ends up “npm info ok”, of course, but that doesn’t make me feel any better about the Wall…
Fortunately, we can work around this anxiety inducing Wall of Red Text with a few npm configuration options. The options you set will be dependent on what you do and don’t want to see.Too Much “info”
The first thing I want to get rid of is the wall of text. Honestly, I just don’t care about seeing all of the information supplied.
The default npm log level for a Docker image is “info” instead of “warn” like it would be on your machine. To fix that, adjust one of two options in your Dockerfile:
In this Dockerfile example, I have set both the “NPM_CONFIG_LOGLEVEL” environment variable and “–loglevel” command-line parameter to “warn”.
You don’t need both of these options in the Dockerfile, though. Pick whichever one works best for you in a given situation.
If you find yourself needing to run npm install multiple times, for example, and you want to ensure npm is always set to “warn”, then I would set the environment variable. This is a great option for a development Dockerfile when you know you’ll be shelled into a container to work with npm. Just be sure to set the ENV instruction before you run npm install, or it won’t have any effect on your Docker build process.
If you only want one specific instance of npm install to have a given log level, however, you can adjust that one call with the “–loglevel” parameter, as I’ve shown.
The end result is a much more manageable output, with only warning and error messages shown… basically, duplicating what you would see on your computer.
But not everyone wants to reduce the output of their build. Maybe you just want to get rid of the red text.Too Much “color”
If you prefer to see the wall of text, but don’t want to see red all the time, you can adjust the “color” configuration setting.
Again, you have two options. Set the “NPM_CONFIG_COLOR” environment variable, or set the “–color” command-line parameter.
The use of these options is basically the same as the previous example. Decide when you want to change the color setting and use the option that is appropriate for your situation.
With the “color” option set to false, as shown, npm will not use any color coding for the log output.
Unfortunately, this means your warning and error messages won’t be in color, either. But if you don’t mind that limitation and you do want to see the wall of text, this is a good option.Can I Get A Red Warning and White Wall?
It’s likely that there is some incompatibility between the Docker log output and npm which is causing the npm Wall of Red Text to begin with. And whatever is causing this is preventing me from getting the output that I really want: white info and red warning text.
Personally, I prefer to set the loglevel to “warn” so this isn’t a huge problem for me. There are times, however, when I want to see the “info” level output and I wish there were a way to get “info” in white and “warn” in red, when using npm with Docker.
For now, though, you’ll have to work with the combination of “loglevel” and “color” in your Docker setup with npm.That’s Great, But How Do I Not Run “npm install” So Often?
Having color and log level control with npm is great. But that doesn’t solve the larger problem of how often “npm install” runs when working with Docker.
It seems everything you do, every time you even think about touching your Docker project, you end up running “npm install” again. It can be a slow, life-draining experience when it happens multiple times per hour.
Fortunately, there are solutions for this as well. With a small adjustment to your Dockerfile and a clever use of Docker volumes, you can create a node modules cache that will easily cut 80% of the “npm install” from your Docker build.
And I want to show you how to do exactly that – to eliminate the npm install delay from your Docker project almost entirely.Tweet
Some time ago, we redesigned the Projects-Teams selector. It became a part of views, and the global selector was removed. This helped to standardize and simplify views, but made it impossible to set Projects and Teams just once and navigate through several views with that selection.
To make this scenario work, in v.3.11.0 we’ve implemented a keyboard shortcut that lets you navigate to a new view with the currently selected Projects and Teams.
As usual, you can select the needed Projects and Teams in the selector on the top of the view (this selection won't override the predefined Projects and Teams for this view).
Explore the data. If you need to navigate to another view with the same selected Projects and Teams, simply hold Alt and click on the view you wish to explore.
As a result, the view will be opened using the Projects and Teams that were selected on the previous view.
You can use Alt+Click to navigate through any number of views with the currently selected Projects and Teams.
For more details on how the Projects and Teams selector works, see the guide post.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Targetprocess v.3.11.0: multiple final states, team mentions, Project selector in Reports, and plenty of fixed bugs.
We've done some housekeeping over the last few months. As a result, the Targetprocess Settings page has a new look and feel. We hope we've made it more pleasant to work with.
As before, you can reach Settings by clicking the gear icon at the top right corner.
We've regrouped all settings into logical sections to make it easier to quickly find the options you need. You may need some time to get used to new grouping, but it makes much more sense arranged this way.
We have completely reworked the Tags section. You can read more about this here. We've also removed the Team section from Settings, as it's more easier to assign multiple users to Projects and Teams right from the Project or Team view. You can read more about this here.
Regular users have access to Import and the Diagnostic and Logs section. Admin users will see the following groups:
Multiple final project states
There used to be no easy way to find out if a closed bug was rejected or fixed.
You can now use multiple final project states for this. For example, let's say I want to set a new kind of resolution for a Bug or Request. I would go to Process Setup > Bug Workflow, set up Rejected and Duplicate bug states, mark them as final, and set the Completed state as the default final state. All 3 states have the semantic of a “final” state — cards in this state will be grayed out, end dates will be set automatically when the entity moves to these states, and filters with 'IsFinal' will be applied.
Multiple final states are not supported if you use Team Workflows.Mention Teams in comments
When you start typing several symbols after an '@' symbol, you will now not only see a list of users, but also a list of teams above the users. If you mention a team, then all its members receive an email notification. In the comment, the mentioned Team (or User) becomes a link to the Team's (or User's) view.Shortcut 'alt+click' opens next View with the current Team/Project context applied
This is a solution that will be helpful for anyone who uses the same set of boards for different Teams or Projects. You can now set your Projects and Teams selection just once and navigate through several views with that selection.
To make such scenarios work, you can do the following: Select the Projects and Teams you wish to see using the selector at the top of the view. To open another view using the selection you just applied, you can hold the ‘Alt’ key and click on the new view in the left menu. For more details visit the post.Project/Team selector added to Process Control, Cycle Time Distribution, Relations Network charts
You will no longer have to set the proper Project or Team before you go into Reports, or have to close a Report to reach the context menu. Now you have a Team/Project selector right in Report Settings.
You can now easily change the selected Project using a dropdown list.
Inactive project cards are now slightly greyed out, as disabled elements usually look like. Hover your mouse over the card to see its details pop-up; all of these units will be greyed out as well.
CSV import Features
We've improved CSV import a bit. Now when you import a batch of Features, you can map them to a parent Epic so that they get to the right place in your work hierarchy.Cards and Axes sorting order unified
We groomed sorting inconsistency a bit. Earlier, Release lanes were sorted by Creation Date while Release cards were sorted by Project. That was a bit weird, so now cards or lanes of the same entity type have a unified sorting order - Releases are sorted by Start Date.Service Desk Widget in Targetprocess
We migrated from UserVoice to our very own Service Desk and updated the 'Contact Us' widget. Now you can post your issues and ideas right from the widget and navigate easily to our Service Desk portal.Fixed Bugs
- You can now send images and attachments in comments with email notifications
- Fixed DSL filters to find items with attachments. The following filters will now work: '?attachments.count>0' and '?Attachments.Where(Name is 'log.txt')'
- Timesheet: time improperly associated a NULL role if added by a user whose role was not responsible for that entity
- Fixed possible effort inconsistency when applying metric results
- Fixed comment losses which occurred if the 'Source' button was clicked twice.
- Timesheet: Fixed transfers to states which require a comment
- Fixed Team state transfer for non-admin users, which failed if Team states were mapped to the last Project state.
- Fixed cache for List views to support complex filters by custom fields
- Fixed effort recalculation for a User Stories if their Tasks are removed or moved to/from another User Story
- Fixed Dashboard TODO widget: filter by entity type apply on first load only
- Fixed Epic > Feature > User Story List views which showed only 25 items and no 'show more' link
- Fixed Requests and Test Plan Run effort units in a List view to be consistent with the entity views
- Fixed improper Initial estimate field population with an Effort value when User Story copies to a new Project
- Fixed export to CSV so that it takes the axes filter into account
- Added the ability to filter entities by a 'None' option in a Multiple selection field ('?MultipleSelectionCustomField is None)
- Fixed Quick Add failures if there are no teams in the system yet
- Fixed mixed Test Plans/Test Cases lists sorting by Business Value column
- Non-required dropdown custom fields which do not have a default value could be saved with an empty value now
- 'Last Run date' unit gets back
- Fixed 'Add & Open' button in quick add in the new inner lists and Relations
- Improved performance of hierarchical test plan run creation
- Fixed a calculated custom field creation error in case its formula uses another custom field but with the same name
- Corrected the error message for an unsuccessful attempt to attach a file that's too large
- Fixed reply comments that could not be deleted if their parent comment was deleted first
- SMTP password length limit expanded
- Fixed Time add from a list in the 'Work Hierarchy' tab
- Fixed Tabular Report 'Assigned Effort' to show names properly (when there are multiple users assigned under the same role)
- Fixed CSV export: checkbox custom field 'false' value used to export as 'null'
- Fixed occasional failure to save Description changes which would sometimes occur even when only one user edited it
- Fixed issue with renaming tags
Enjoy this excerpt from the Lean Business Report. Learn the 7 traits of high-performing Lean teams, as reported by 3,000 survey respondents.
To summarize: your agile transformation is stuck. You’ve thought about your why, as in Becoming an Agile Leader, Part 1: Define Your Why. You’ve started to measure possibilities. You have an idea of who you might talk with as in Becoming an Agile Leader, Part 2: Who to Approach. Now, how do you create allies so you can unwedge your agile transformation?
First, here’s a big question: do you have a relationship with this person? If so, terrific. You have options as below. if you don’t have a relationship yet, it’s time to build a relationship.
Let’s assume you have some sort of relationship with this person. In that case, you might ask for coaching.
You might say, “Hey, wait a minute, Johanna. I’m the coach (or leader in some way). Why would I ask for coaching?”
When you ask for help, as in coaching, you offer your other person (often called a client) a gift. You offer explicit permission to explore options with the other person’s support. This is especially helpful if the other person is your peer or is senior to you in the hierarchy.
I know, this is turning the normal definition of coaching around. Many people think that if they are one of the agile transformation leaders , they have to have all the answers. No, you don’t. You might not know what the smallest possible change is. You might not be aware of the forces that prevent change (I’m assuming good intentions on everyone’s part). You might not know what this person might gain or lose with an agile transformation.
Asking for help is a sign of strength, not weakness. Asking for help shows transparency and a willingness to consider other options.
You might “lead” the coaching conversation by saying something like this: “Here’s what I’m seeing. We’ve done this and that and gotten these results. Do you see the same things?” If the person has different data, wow, that’s great to learn. If you have the same data, you might continue, “I’m concerned we’re stuck. I see these options to solve these problems. Do you see something else?”
When you ask for other options, you open the conversation (and your brain) to possibilities you might not have seen before.
This coaching conversation is very different from, “I’m the agile expert and I’m here to help.” You might be the agile expert. You are definitely there to help. And, you need to enter the other person’s context to understand what’s going on for that person.
You might be thinking, “Oh, this is going to take time.” Well, it will. These are one-on-one conversations. You might have to wait a week to get on someone’s calendar. And, what have you got to lose? What’s the worst thing that can happen?
If you want to experience this kind and other kinds of coaching conversations in the context of helping your agile transformation continue, join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.
My next post is about exploring how you use influence aside from coaching to achieve win-win scenarios.
Not too long ago, we ran into an apparent security issue at my current assignment - people could sign in with a regular account, but get the authentication and permissions of an administrator user (a privilege escalation bug). As it turned out, the impact of the security issue was low, as the user would need […]
In a recent scan of the e-literature on the reciprocal impact of Agile on HR, I connected some very interesting insights which I’d like to share. A set of insights that looks like ripples across the surface of a pond. Ripples that started when the Agile stone was thrown into the pond in 2001. In its simplest form, Agile is about a different way of working with each other in teams. Teams that are cross-functional, collaborative, co-located and customer-driven in their decision making. The insights provide compelling reasons why HR needs to take an active role in Agile implementations.Insight #1
“In the most successful Agile transformations, HR is a driver of the change and a key hub that steers other departments’ success.”
HR certainly needs to be ‘a’ driver in the change, but not ‘the’ (sole) driver. Rather they need to partner in the change. Successful Agile transformations will benefit from HR’s expertise in
- Organizational Effectiveness
- Learning & Development
- Workforce Planning & Talent Management
- Total Rewards
The driver of the change, historically IT, will need HR’s help to manage the impact to people and traditional HR processes/tools. As the change scales and starts to impact other departments in the business, HR can play a large role in ensuring the business overall stays aligned in delivering end-to-end value to customers.Insight #2
“2016 will be the year of Agile HR… most HR teams have no clue what Agile HR means.”
(HR Trend Institute)
Agile was a hot topic for HR in 2016 as evidenced by the number of times ‘Agile HR’ has made the shortlist of topics being brainstormed for HR conferences and networks. It was the #1 trend on the 2016 HR Trend Institute list. Its popularity is not cooling off in 2017. And yet most HR teams still don’t have a clue what ‘Agile’ means, never mind what ‘Agile HR’ means.Insight #3
“As the world becomes more volatile, organizations need to find ways to become highly agile. HR will need to support a world where people may no longer have predefined ‘jobs’ that lock them into doing one activity.”
Agile has entered the mainstream. A necessity given the VUCA world we live in. Agile is no longer the sole domain of IT. The common refrain from all C-suite leaders these days is increased agility and nimbleness across the entire business – not just IT. The impact of capital ‘A’ Agile or small ‘a’ agile will affect HR. People will no longer have predefined jobs – People’s career paths will change. In this VUCA world, standardized career paths are no longer effective. Batch-of-one career paths will become the norm.Insight #4
“HR’s job is not just to implement controls and standards, and drive execution—but rather to facilitate and improve organizational agility.”
The HR profession itself has been going through its own transformation. The HR profession has evolved from an administrative and transactional service to a strategic business stakeholder with a seat at the executive table. The role of HR now includes a focus on organization-wide agility and global optimization of departmental efforts.Insight #5
“Human capital issues are the #1 challenge for CEOs globally.”
(The Conference Board CEO Challenge 2016)
The Conference Board’s 2016 survey of global CEOs ranked human capital issues as the number one challenge. It has been number one for the last four years in a row. Within that challenge, there are two hot-button issues:
- Attracting and retaining top talent
- Developing next-generation leaders
The adoption of agile ways of working will change
- How we recruit and engage
- How we nurture and grow not only our leaders but our talent in general
In the words of Robert Ployhart, “…employees don’t just implement the strategy – they are the strategy”. CEOs around the world would tend to agree.
The net of these insights is the more HR professionals understand Agile and its implications, the more effective Agile or agile initiatives and people/strategy will be.
I’d like to see HR ride the wave.
 VUCA is an acronym introduced by the US military to describe a state of increased Volatility, Uncertainty, Complexity and Ambiguity
 Ulrich, Dave, William A. Schiemann, Libby Sartain, Amy Schabacker Dufain, and Jorge Jauregui Morales. “The Reluctant HR Champion?” The Rise of HR: Wisdom from 73 Thought Leaders. Alexandria, VA: HR Certification Institute, 2015. N. pag. Print.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Today Agile is generally recognized in IT as generating far more business value than previously possible using traditional methods. However, the financial benefits that businesses actually obtain from their investment in Agile fall far short of what potentially could be achieved. In this series we revisit the original white paper “The Business Value of Agile Transformation” in an effort to do away with the IT jargon and domain specific references and help business get the full benefits of their Agile initiatives. We will review each of the six business benefits of Agile transformation and reframe the conversation for the new realm of Business Agility. They are:
- Reduced failed project risk
- Reduced over-budget and late projects
- Reduced waste
- Improved return through early and frequent releases
- Reduced write-off risk
- Higher-quality software with fewer defects
Here, we consider how Agile reduces over-budget and late projects. Read Part 1 on reduced failed project risk here.
Benefit 2: Reduced Over-Budget and Late Projects
Knowledge work is a complex, organic process, which makes it inherently difficult to estimate when it will be complete or how much it will cost. Knowledge work is a creative design process that calls for the integration and development of emergent ideas. This is a different kind of work than, for example, the construction of a house from a detailed blueprint. The ability to predict when the house will be done is easy because there is an exhaustively complete specification to work from and the type of labor needed to build it (drywalling, plumbing, etc.) is highly fungible. That is to say, the variance between how experienced tradesmen will conduct the work and how long it will take is very small. Finally, since the desired outcome is inert and physical in nature, it’s easy to verify that the outcome comports with the specification. Because you can calculate how much time and labor will be needed, you can accurately estimate the cost. Very little design work occurs during house construction: the design work is conducted prior to the construction phase by the architect. For construction projects, the ration of design work to construction work is very low. However with knowledge work in a commercial setting that pattern is reversed.
For example, coding software from software specifications is a design process. The actual construction process begins when the software is compiled and released to production — a tiny fraction of the overall effort. The same pattern holds for any kind of knowledge work. For example, most of the time spent by a management team developing corporate policy is spent in discussions and meetings. This is a design process. The construction process — drafting the policy document — is comparatively trivial. How much time will be needed depends upon how long it takes to reach a consensus. Could be one meeting, could be a year.
The big mistake that organizations have made that result in over-budget and late outcomes is using project management techniques designed for construction on design projects. In software projects, for example, traditional approaches often attempt to predict with precision what will occur a year or more down the road before the project begins. However, with no reliable way to accurately predict the cost or time needed, these estimates are largely unreliable no matter how much effort is expended to develop them. Traditional milestone segmentation of project schedules won’t solve this problem, since there is no way to accurately measure the completeness of project artifacts until late in the project schedule. The result is poor project performance. Projects are either late with overrun budgets or contingency buffers are used to improve estimates at the cost of diluting project outcomes and inflating costs.
Agile methods address these problems in a number of ways:
- By empirically measuring the time it takes to complete a short increment of delivered work, you can project a fact-based estimate of the time and effort needed to complete the rest of the work. Initially the confidence interval is wide and narrows over the course of the project.
- By completing all the work necessary to deliver a slice of requirements during the iteration, you can more accurately measure the percent of work completed. The fallibility of the traditional milestone approach is avoided.
- Continuously re-estimating work over the course of the project encourages the use of the best information available and “truth telling” even if it contradicts initial estimates.
- Team artifacts such as “definition of done” are used to ensure that all necessary work is completed during each iteration. This also helps makes notoriously abstract knowledge work more concrete.
- Frequent demos of work in progress (WIP) that depend on visualizations and simulations of outcomes rather than comparatively abstract text make it easier for customers and stakeholder to recognize progress is or is not being made and provide useful feedback that incrementally improves the course and content of the initiative.
- Shorter release cycles means shorter forecast time horizons, which means more accurate estimates.
- Because short term estimates can be quickly confirmed they help identify trends early on. This means that schedule and budget problems are forecast early, leaving more time to implement the proper mitigations.
- Because the first production release is delivered much earlier than would otherwise be possible, the chance of complete failure is dramatically reduced. Early release also provides opportunities to reduce project scope and corresponding costs.
More and more Agile techniques are found to be a better fit for design projects such as software development than traditional methods. What more people are coming to understand is that these techniques will work for any kind of knowledge work. This includes, management teams, marketing teams, digital media content production — you name it. It is not true that collaborative design activities can’t be managed or estimated. You just need to use the right techniques — techniques designed for that express purpose: Agile techniques.
Next up is how Agile reduces waste.Want to Skip to the Head of the Class?
Download the white paper that started it all. In “The Business Value of Agile Transformation”, SolutionsIQ CEO John Rudd discusses six business benefits that can be measured using traditional financial and production metrics and that are available to any Agile enterprise.
The post Revisiting the Business Value of Agile Transformation, Part 2 appeared first on SolutionsIQ.
To summarize: your agile transformation is stuck. You’ve thought about your why, as in Becoming an Agile Leader, Part 1: Define Your Why. You have some idea for measurements. Maybe you’ve even started to measure to capture the data.
Now, it’s time to talk to people across the organization. The question is this: Who do you talk with, to unwedge your agile transformation?
You know that the org chart is one way of seeing the system. And, there are many other ways to see your system. One way is an organizational map.
The organizational map helps you see who might have interests, pain, or power in different areas of the organization. You can then decide who and how to approach each of those people. Given their interests, you have some idea about how they might respond.
Every single time I’ve worked with people to create their organizational maps, they have learned something. Most often, they realize that someone else in a corner of the organization has key information for agile success. Sometimes, the transformation advocate realizes that another person has less or more power than we expect. Sometimes, the agile advocate realizes that if they supply some key measurements, they might be able to unlock the agile transformation.
Sometimes, people are surprised that developers or testers are the people with power and help. Sometimes, it’s people across the organization, such as someone in Finance or HR. Your transformation allies can be anywhere in your organization.
The organizational map helps you see who is helping your agile transformation, who is neutral, and who is not helping. This map, with names blacked out, is from participants at last year’s Influential Agile Leader.
In my experience, the people who are neutral or not yet helping are not “resisting change.” They are not skeptics, although they may act skeptical. Here’s what I have found most often: they haven’t discovered the usefulness of agile to achieving their goals.
If I understand the why for agile and understand their interests, power, and pain, I have an entry into asking them what their goals are, especially if the map didn’t make that obvious.
Nurturing and maintaining an agile transformation is hard work. I like knowing who I should talk to, to make sure I’m gaining the most benefit from all of my work. I can gain allies in my measurement-gathering and in the actions I want to take for the agile transformation. I might even consider a change for how to transform the organization.
If you want to learn how to create an organizational map, join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.
My next post is about how to approach these people, especially peers and people senior to you.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Jeff Sutherland points the fickle finger of fate at Ken Schwaber for starting this fable:
I've hated having to tell teams this joke... the lore of the Scrum pig and chicken is so pervasive that before long someone is going to call someone else a chicken (or a pig)... and then you have to tell the joke to help that person retain face... it can be quite uncomfortable for me.
I think my disdain for this joke has to do with two of American's least favorite farm animals being featured. We call people chickens to say they have little courage. We call people a pig to insult their appearance (clothing choices, weight, manners). Had the joke featured a cat and dog... it would be so different - wouldn't it?
Now Jake it appears has taken this joke metaphor to a new level... good job Jake!
Some fun videos about Agile & ScrumScrum cartoons and fictional stories - a list
Scrum Pig and Chicken - part 1 by Jake Calabrese
Organizational Commitment: Pig and Chicken – Part 2 by Jake Calabrese
Does Your Culture Require Your Demise - Pig & Chicken part 3 by Jake Calabrese
Product team is starting to assign business values to epics so we can, along with effort estimates, set correct priorities. However, we also have quarterly goals. Once we reach the end of a quarter, if an epic is not completely done (all stories under it), how do we get partial credit?Answer
I recommend rolling the value down from the epics into the stories themselves. This way, you can see what you delivered in the quarter. Keep in mind that value estimates, just like effort estimates, are really just a tool to help with planning and decision making. At the end of the quarter, I’d like to see you focusing on the awesome stuff you delivered and what your customers’ reactions were to that new functionality.
I also recommend not trying to complete all of the stories in the epic. That type of ‘completion thinking’ is often a holdover from the old way of thinking: “We must do all of the things that we said we would do.” It’s not usually the best approach. When a big epic is broken into smaller stories, it’s not the case that all of the stories are equally valuable. Some are very valuable, many are fairly valuable, and some are nice to have but not really all that valuable. Deliver the most valuable stuff, and then keep an eye out for when the rate of value delivery is falling off. At that point, there is usually other, more valuable stuff that the team could be working on. So you should have the team stop working on the current epic, and move on to the other more valuable stuff. Free yourselves from ‘completion thinking’ and focus on constantly delivering value at the fastest possible rate.
Several years ago, I found myself sitting in a classroom on a Saturday morning.
It was an exciting day for me, attending my first code camp. I was surrounded by other developers with a shared enthusiasm for what we do, and had already seen several outstanding presentations.
The subject for the classroom in which I now sat was Resharper – a plugin for Visual Studio that added an incredible amount of power and flexibility for editing and restructuring code. I knew the basics, already, having installed it on my computer at work. But it was not something I felt I knew how to use efficiently.
Sure, I could click the squiggly red lines and the pop up menu that came with Resharper. But I knew there was more to it than this. I knew there had to be a reason beyond these simple, surface level features that made so many developers so excited about it.
That’s what made this Saturday morning session so important – knowing that I was about to see the real power of this tool.
With fluidity, the presenter demonstrated feature after feature. I was enthralled by the ease at which he edited and restructured code. More than anything else, though, I marveled at how he used Resharper’s features without once touching a mouse or trackpad. There were no arrow keys used to move around the menu system, either. It was all keyboard shortcuts and commands.
Furiously, I scribbled notes. I knew this was just the thing I needed, and I wanted to copy every technique shown. I could see in my mind, just how easy life as a developer was about to become!
Fast forward to Monday morning at the office. Opening my project in Visual Studio, I start editing code, excited about the opportunity to use Resharper with my new-found efficiency.
A moment later, I saw my opportunity. Checking my cheat sheet, I pressed a few buttons on my keyboard, and …
Wait. That wasn’t the feature I wanted.
Quickly, I checked my notes and tried another key combination. Again, it wasn’t the feature I wanted. I tried again. And again. And a few keyboard clicks later, I hit a brick wall.
Every last ounce of enthusiasm and excitement I had was draining – fast – to be replaced with a sinking feeling, like I was struggling in quicksand. Reluctantly, I reached for my mouse and clicked the drop down menu to find the option I was looking for.
It wasn’t enough to have the tool or to know the features existed.
There was a level of efficiency that eluded me, still. One that I wanted. One that I had seen the previous Saturday. But one that I could not seem to achieve.
And so it is with many of today’s tools for modern software development. Simply having the tools available – and even the ability to use them – doesn’t create efficiency.
Take Docker as a more modern example.
Once you learn the basics, it can offer a tremendous amount of value in development, testing, deployment and beyond. But the value it offers doesn’t imply anything about efficiency of use.
It only takes a few instructions in a Dockerfile to create a working Node.js application, for instance.
But with this Dockerfile – pulled directly from a recent project I built – efficiency is not a word that comes to mind.
The problem is that efficiency can only be measured in light of a goal. So what’s the goal here? To write a Dockerfile in as few instructions as possible? I would think not.
Rather, the goal should be to write a Dockerfile that runs the application as expected, and is able to be built and re-built as quickly as possible.
If you were to build a Dockerfile like the one shown, your project would run quite well. However, every time you need to rebuild the Docker image, you will incur another full round of “npm install”.
This doesn’t sound too bad until you realize that every line of code change and every tweak to the environment configuration requiers a rebuild and another round of “npm install”.
You can start to work around this with a host-mounted volume for editing code, of course. In fact, this is encouraged. It means you don’t have to rebuild your image every time you change a line of code.
But now you’re faced with a new problem: host-mounted volumes are notoriously slow. What was once a 2 to 3 minute install for your dependencies is now more like 5 to 10 minutes. And every time you decide you need to rebuild your base image or start a new container in which you want to install development dependencies, you’re stuck waiting for “npm install”. Again.
How, then, do you create efficiency in building and maintaining your Docker image, to match the value that Docker brings at runtime and deployment?
The short answer is to use the tools you have, more effectively.
When used correctly, Docker can cache your Node.js modules for you, eliminating the npm delay from your Docker projects almost entirely.
This isn’t the same kind of caching as the web, though. You’re not using a better CDN, a browser cache or proxying the HTTP requests to another server. You’re not switching package managers, either.
What kind of cache is it, then, if not the kind of cache that we build with web apps or a different package manager?Tweet
The post Are Your Development Tools Making You More Efficient? appeared first on DerickBailey.com.
Your agile transformation isn’t proceeding the way you thought. People use the right agile words, but they’re not changing how they work. Teams aren’t collaborating, managers still talk about “resources,” and the projects aren’t delivering finished value. Your agile transformation is stuck.
Maybe it’s time to return to your why. Why is your organization moving to agile? Do you know?
Ask the people who wanted agile these questions:
- What is valuable to us?
- How will we measure what is valuable?
- What is the first deliverable we can achieve to provide value?
When you ask these questions, people start to remember why they wanted agile in the first place. I’ve heard answers like these:
- We want to release something more often than once a year (or longer).
- We want to increase the quality of our products.
- We don’t want to hear customer complaints as often, for releasing or bug reports.
- We want to have fun.
- I want to master this code base.
- I want to learn how to automate which tests.
- I want to feel as if I’ve done a great job.
Managers often want to see revenue increases, customer happiness, and a decrease in the cost of providing customer support and project cost. Teams often want more satisfaction with their work and a feeling they have done right by the customers.
If you are an agile leader, you can develop measurements to help both sides see what they’re aiming for and how to get there. These measurements help people see why they are changing and if they are accomplishing the change—the why. But, first you have to know the why. (And, don’t be surprised if everyone has a different why!)
In my next post, I’ll address how you define who to talk to. It might not be obvious.
I’m writing this series of posts so you might consider joining us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]