In LeanKit, Drill-Through Boards help you track and manage the execution of company initiatives by providing the right level of visibility to the right people. This allows you to visualize your plans at a high level and dig deeper into the implementation details as needed. Learn how to set up and use Drill-Through Boards at […]
I wanted to start off this blog with a succinct definition of “Hardening Sprint” so we are all on the same page. I couldn’t find one. I found a lot of words on the Scaled Agile Framework site that talk about and apparently justify Hardening Sprints if you want to read that.
I decided to work up a quick definition of a “Hardening Sprint” myself:
A pre-planned iteration in which we will do all the things we should be doing all along, but won’t.
I’m reminded of a particular label that is very common on candy in stores these days.
It’s still candy, being fat free has nothing to do with the fact that it’s just as fattening as it ever was, being pure sugar. So why put that label on it? Simply stated we humans really like to justify bad behavior by lying to ourselves.
Here’s the thing, I don’t get worked up about Hardening Sprints because of the activities in them. They are most likely perfectly legitimate things that we need to do. My problem is that if they are Backlog Items we need to accomplish, then we don’t work on them in a “Hardening” Sprint, we just work on them in a Sprint. That’s all a Sprint is, an time box during which we work on the Backlog Items that we have committed to.
When we plan ahead for a specific sprint in which we will do the things we should have been doing all along we excuse the bad behavior. We tell ourselves it’s OK to put off what we should be doing today because we will just get that in a later phase of the project. That’s just Waterfall, which could be perfectly fine by the way, but if that works for you just call a spade a spade and admit you are still practicing Waterfall. Scrum isn’t the answer to everything.
Odds are in your Scrum project you may legitimately need some sort of release sprint, some period of time to put the finishing touches on everything before it goes out the door. This isn’t any different then any other sprint, but if we are setting side that time for additional testing (which we should have been doing all along) we are admitting we aren’t good enough to fix our process.
We are eating “Fat Free” candy and expecting to lose weight.
Scrum is hard, testing as we go is hard, being committed to solid technical practices is really hard. If we don’t deliver fully functional, tested, deployed, integrated (insomuch as we may be able to in test environments if we can’t push straight to live) pieces of business value with every Backlog Item we complete we aren’t going to be successful in our Scrum practice. Hate to break it to everyone, but Scrum is a disciplined framework that is just flat out hard.
If you are throwing in the towel, and saying to yourself; “We need Hardening Sprints”. I think you are selling yourself and your organization short. You can do it, the technology, frameworks, and practices are there to support you, and your competitors are most likely doing it. So why not you?
Be sure to register for my upcoming agile webinar: Grasping Agility: A Guide to Building an Agile Organization, Wednesday, July 9, 2014 – 8:00-9:00 AM PDT.
The post Grasping Agility; Hardening Sprints: A Fat Free Candy! appeared first on blogs.collab.net.
Kanban and continuous delivery are technical practices that go hand in hand. The goal of continuous delivery is to rapidly, reliably and repeatedly deliver new features and bug fixes at low risk and with minimal overhead. The goal of Kanban is to optimize the flow of work through incremental change. Both approaches share the common […]
The post How Kanban Enables Continuous Delivery: LeanKit’s Perspective appeared first on Blog | LeanKit.
One of the twelve Agile principles states "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly" . Many Agile teams have retrospectives every two weeks that result in concrete actions that are executed in the next time period (sprint). There are many types of tuning and adjustments that a team can do. Examples are actions that improve the flow of work, automation of tasks, team coorporation.
Is it good habit for retrospectives to focus on the same type of improvement or should the team alter the type of improvements that will be done? In this blog I will look into the effect of multiple consecutive actions that affect the flow of work.
The simulation is inspired by the GetKanban game .An Experiment
Ideally one would have a set-up for an experiment in which two exactly equivalent teams are compared. One team that would perform consecutive actions to improve the flow of work. The other team would just make one adjustment to improve the flow, and focus subsequent improvements on other areas than flow. At the same time the flow is measured and verified after a certain period of time whether the first or the second team has achieved better results in terms of flow.
Such an experiment is in practise (very) difficult to perform. In this blog I will study the same experiment by making use of simulations.Simulation
For the purpose of simulation I consider a team consisting of three specialists: 1 designer, 1 developer, and 1 tester. The team uses a kanban process to achieve flow. See the picture below for the begin situation.
In the simulation, at the beginning of each working day it is determined how much work will be completed by the team. During the simulation the average cycle time is measured. The initial Work in Progress (WiP) limits are set to 3 for each column and is indicated by the red '3's in the picture.
The average amount of work done by the 'team' and the average effort of one work item are such that on average it takes one card about 5,5 days to complete.
At the end of each work day, cards are pulled into the next columns (if allowed by the WiP limits). The policy is to always pull in as much work as allowed so the columns are maximally filled. Furthermore, the backlog is assumed to always have enough user stories ready to be pulled into the 'design' column. This very much resembles developing a new product when the backlog is filled with more than enough stories.
The system starts with a clean board and all column empty. After letting the system run for 75 simulated work days, we will trigger a policy change. Particularly the WiP limit for the 'design' is increased from '3' to '5'. After this policy change the system runs for another 100 work days.
From the chart showing the average cycle time we will be able to study the effect of WiP limit changing adjustments.Note:
The simulation assumes a simple uniform distribution for the amount of work done by the team and the effort assigned to a work item. I assume this is OK for the purpose of this blog. A consequence of this, is that the result probably can't be scaled. For instance, the situation in which a column in the picture above is a single scrum team is not applicable since a more complex probability distribution should be used instead of the uniform distribution.Results
The picture below shows the result of running the experiment.
After the start it takes the system little over 40 work days to reach the stable state of an average cycle time of about 24(*) days. This is the cycle time one would expect. Remember, the 'ready' column has a size of '3' and the other columns get work done. So, one would expect a cycle time of around 4 times 5,5 which equals 22 days which is close to 24.
At day 75 the WiP limit is changed. As can be inferred from the picture, the cycle time starts to rise only at day 100 (takes about 1 cycle time (24 days) to respond). The new stable state is reached at day 145 with an average cycle time of around 30(**) days. It takes 70 days(!) to reach the new equilibrium.
The chart shows the following interesting features:
- It takes roughly 2 times the (new) average cycle time to reach the equilibrium state,
- The response time (when one begins to notice an effect of the policy change) is about the length of the average cycle time.
(*) One can calculate (using transition matrices) the theoretical average cycle time for this system to be 24 days.
(**) Similar, the theoretical average cycle time of the system after policy change is 31 days.
In this blog we have seen that when a team makes adjustments that affect the flow, the system needs time to get to its new stable state. Until this state has been reached any new tuning of the flow is questionable. Simulations show that the time it takes to reach the new stable state is about 2 times the average cycle time.
For scrum teams that have 2-week sprints, the system may need about 2 months before new tuning of flow is effective. Meanwhile, the team can very well focus on other improvements, e.g. retrospectives that focus on the team aspect or collaboration with the team's environment.
Moreover, don't expect to see any changes in measurements of e.g. cycle time within the time period of the average cycle time after making a flow affecting change.
To summarise, after making flow affecting changes (e.g. increasing or decreasing WiP limits):
- Let the system run for at least the duration of the average cycle time so it has time to respond to the change,
- After it responds, notice the effect of the change,
- If the effect is positive, let the system run for another duration of the average cycle time, to get to the new stable state,
- If the effect is negative, do something else, e.g. go back to the old state, and remember that the system needs to respond to this as well!
 Agile manifesto, http://agilemanifesto.org/principles.html
 GetKanban, http://getkanban.com
On Wednesday, June 18th, we will be supporting our friends in the Jenkins and CD communities at the Jenkins User Conference in Boston. See you there.
We use Jenkins heavily here at Assembla, and we provide a number of integrations. Here are some blog articles.Fun with Jenkins
Some things we do with Jenkins:
Jenkins oAuth plugin enables jenkins to access Assembla API without giving up user credentials to Jenkins. https://public.assembla.com/code/assembla-oss/git/nodes
Jenkins Assembla Merge Request builder - https://public.assembla.com/code/assembla-oss/git-2/nodes - lets you automatically generate Jenkins jobs for new merge requests in a specified repository, using templates to create the jobs. It constantly polling Assembla API and in case of new Merge Request detected, plugin creates new build-job.
Run Jenkins under an Assembla tab. At Assembla we have custom tool tabs, where our jenkins lives. Using oauth jenkins plugin + Assembla API, we allow our developers to authenticate on jenkins, right in place without leaving our private development space.
Use Jenkins for Continuous Delivery at Assembla, with an amazing build process so that we can test and release every change, independently. All development is done in private developers forks, in branches. After developer pushes to the remote branch, and create merge request from branch to upstream master, jenkins automatically picks up this change.
- It runs a test suite. So, every change can be tested by a computer before it is reviewed by a human.
- It automatically deploys from given branch to newly created EC2 amazon instance. This gives our QA and product managers an easy way to find and test the change.
After QA or product owners look at the staged branch, we proceed to production deploy. The system merges to upstream master and deploy actual code to production.
After the merge, Jenkins automatically cleans up. It removes jobs, builds and EC2 instance.
You could use Salt to build and run Docker containers but that is not how I use it here. This blogpost is about Docker containers that run Salt minions, which is just an experiment. The use case? Suppose you have several containers that run a particular piece of middleware, and this piece of middleware needs a security update, i.e. an OpenSSL hotfix. It is necessary to perform the update immediately.
In order to build a container you have to write down the container description in a file called Dockerfile. Here is the Dockerfile:
#------- # Standard heading stuff FROM centos MAINTAINER No Reply email@example.com # Do Salt install stuff and squeeze in a master.conf snippet that tells the minion # to contact the master specified. RUN rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm RUN yum install -y salt-minion --enablerepo=epel-testing RUN [ ! -d /etc/salt/minion.d ] && mkdir /etc/salt/minion.d ADD ./master.conf /etc/salt/minion.d/master.conf # Run the Salt Minion and do not detach from the terminal. # This is important because the Docker container will exit whenever # the CMD process exits. CMD /usr/bin/salt-minion #-------
Build the image
Time to run the Dockerfile through docker. The command is:
$ docker build --rm=true -t salt-minion .
provided that you run this command in the directory where file Dockerfile and master.conf resides. Docker creates an image with tag ‘salt-minion’ and throws away all intermediate images after a successful build.
Run a container
The command is:
$ docker run -d salt-minion
and Docker returns:
The Salt minion on the container is started and searches for a Salt master to connect to, defined by the configuration setting “master” in file /etc/salt/minion.d/master.conf. You might want to run the Salt master in “auto_accept” mode so that minion keys are accepted automatically. Docker assigns a container id to the running container. That is the magic key that docker reports as a result of the run command.
The following command shows the running container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES 273a6b77a8fa salt-minion:latest /bin/sh -c /etc/rc.l 3 seconds ago Up 3 seconds distracted_lumiere
Apply the hot fix
There you are: the Salt minion is controlled by your Salt master. Provided that you have a state module that contains the OpenSSL hot fix, you can now easily update all docker nodes to include the hotfix:
salt \* state.sls openssl-hotfix
That is all there is to it.
Last week, 22 Assembla team members came together from 10 countries to solve current problems and make plans for the next year. We met in beautiful Antalya, Turkey, over the Mediterranean, which the Turkish call the "white sea." We gained new energy and new momentum.
Assembla.com VP Sergey Golub wrote:
I would like to thank all of you for productive technical discussions and business ideas, for presentations you've made, for brainstorming big and small problems, for playing football/ping-pong/backgammon/chess together, for jumping in the waves in the sea and for lazy laying around a pool together, for singing in the bus during our travel and long walks in old city, for dancing turkish dances, for special English lessons and a lot of fun.
Sergey himself scored four football/soccer goals with a rocket right leg and grabbed a guitar from a local tavern performer to serenade us on Wednesday evening.
We worked at least 8 hours each day, from 8:30 to 12:30, then broke out for beach/gym/lunch from 12:30 to 14:30, then met again from 14:30 to 18:30.
A few of the concrete results were:
- We feel the need for speed, delivered by database upgrades and sharding.
- We will continue to break Assembla into smaller services and implement the MAXOS pattern. This is a megatrend that all of our development and ops guys are excited about.
- We will help you manage more of your Fast IT projects faster with a top level Portfolio Cardwall showing projects as them move through various stages, with summary reports. The wireframes and customers interviews for this are already well advanced.
- While we were there, we implemented the top request from our GitHub tool users allowing you to add multiple GitHub repositories in an Assembla project. This makes it easier to use Assembla's ticket and project management tightly integrated with GitHub repositories.
- We finished wireframes to reorganize the repositories under one tab, where you can easily access and add Git forks, Subversion, P4, GitHub or Bitbucket integration, deploy tools, and more - all of your coding needs in one place.
- We created a status page so users can easily view of the heath of our services with the ability to subscribe to real time communication.
- We will be trying out some experimental services to help you "get it done now." That's all I can say about it.
Thanks to the team, it was a lot of fun. Check out some pictures from our trip below:
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Any UX designer wants to create a software tool or an app that would appeal to users. Designers employ various techniques and practices to emulate users’ behavior or to define user behavior flows, and it’s a common belief that these techniques are all they need to design a successful product. However, there’s one cornerstone to all the things UX that often remains neglected, as I was able to observe. It’s hardly that the techniques alone would take UX designers to where they want without this essential base. I’ll try to shed some light on what that is.
It seems that UX design practices can be roughly broken down into the following:
- Designer toys
- User mirrors
- A mix of both the above
Let me explain. What I call “designer toys” are the techniques that designers commonly use to better define their own vision of how users will behave inside an interface. What I call “user mirrors” are the techniques used to gather evidence, factual or intuitive, of how users want to behave in the context of a user interface. These mirroring techniques include all kinds of A/B testing, surveys, etc., and it is assumed that designers exercise empathy with users.
With the mix of designer toys and user mirror techniques, the outcomes of A/B testing and feedback from users are taken into account for new design versions. Having received certain signals from users, designers then use wireframing, personas, storyboarding, Design Studio methodology, a pinboard for design ideas, sketching, paper prototypes, etc. This mixed approach will be mostly required to improve an existing product or an app.
However, those many techniques fall short in the face of one ultimate deal breaker (or deal closer). Interaction design, or user interface design for that matter, is supposed to facilitate interaction between a user and an interface in a context shared both by a user and a software product. A friend of mine puts it that way:
The hows will appear if the what becomes clear
No sketching or wireframing technique will ever help communicate the strengths of a product or an app. If users act in the context that differs from what is implied by designers, or by the whole product dev team, it’s likely that subtle UI perks and niceties will hit the barren ground. A very drastic example: can you imagine a pre-historic human using an iPad? It took millions of years to bring this living being to the context in which an iPad gives a clear “what”.
On a softer level, Facebook was able to hitchhike along with users because everyone wanted to stay connected to their friends online. It’s a whole other story that now, after about 10 years, we’re witnessing the opposite trend, and Facebook is in decline.
So, the ultimate thing that makes for a success of a product would not be a user interaction design, or UX design. This whole user+product=love thing can only happen if users and product makers share one vision. It’s very *cool* when one only needs to analyze the needs of users who act within one established paradigm of thinking. Things get a lot more exciting when the vision that a product team brings into the world is innovative, and users are not yet fully aware of what this product can do for them. In this case, playing with designer toys will resemble shooting at a target randomly in sheer effort to hit the bull-eye. It won’t work. User vision design comes first, UX design goes next. UX design is more of a technician activity, because once a shared vision of something exists, people usually do not make any big difference with their designs, they mostly borrow tricks from each other and follow each other’s steps.
Designing user vision is a whole other story. It involves having a clear product vision in place with the insiders (product dev team/executive/designers), and their ability to communicate this vision to the outsiders. Insiders need to come up with compelling proofs of how their product helps people do things better/easier, from a totally new perspective. Social sharing apps capitalize on the designed user vision that social sharing is hippish. Another case of user vision design is promoting Big Data as a panacea for organizational problems. Agile software development methodology has produced a vision for users as well. I can go on with more examples, but you get the idea.
UX designers need to keep in mind that successful design goes far beyond graphical or interaction design. For innovative products, it also includes user vision design.
We are happy to announce that you can now add multiple GitHub repositories within any Assembla project. Note: The same update was also applied to our Bitbucket tool/integration which works similarly to the GitHub tool discussed below.
If you are not familiar with the GitHub tool, it allows you to integrate GitHub repositories with Assembla’s tickets and activity stream. Previously, projects were limited to one GitHub repository per project, but a recent survey concluded that the biggest improvement we could make to the integration was to allow multiple GitHub repos per project. We listened.
While Assembla is well known as the best Subversion host, as well as a rock solid Git host, we understand that our users may prefer to use GitHub (or Bitbucket) for various reasons. Existing users already using the GitHub tool expressed their love for being able to use GitHub seamlessly with Assembla’s ticket, collaboration, and project management tools. Instead of fighting this, we want to embrace it with a seamless integration that we will continue to improve.
“Assembla's GitHub integration allows our team to enjoy the best of both worlds - GitHub's developer community and team development features tightly integrated with Assembla's task planning and tracking, wikis, and other project management tools. We can easily reference and update Assembla tickets with GitHub commits and see all project activity in one unified stream via Assembla. The combination of tools works great for our team."
Michael Katz, Principal Software Developer, Kinvey
To add a GitHub repository to your Assembla project, visit the Admin section > Tools page > and click ‘Add” next to the GitHub tool. Once one has been added, the button will now say ‘Add Another’ to add multiple GitHub repositories. Once the tool has been added, you can click on it in your navigation > enter your repository URL > and follow the on page instructions to finish setup.
Thank you everyone who participated in the survey that lead to this improvement. If you have any other feedback regarding this integration, or improvements to any other tools, please visit our feedback site.
If you do not have an Assembla project and would like to check out this integration, try Assembla out for free.
We have been running agile testing workshops for a few years, and given some talks at conferences. It seems there is lots of talk about agile testing going around. But what does it really mean? How do you know if your testing is agile or not?It’s not agile testing if…
Below are some signs that your testing strategy is not all that agile.
- Your testers don’t have much to do at the start of a sprint, but are always rushing to finish testing before the sprint end.
- Your developers run ahead of the testers and start working on stories in future sprints while they wait for testing to catch up.
- You have a manual regression phase before a release.
- Developers write code before test cases are discussed.
- Tester’s get to decide if a build should be released or not.
- You have a separate test or QA team.
- You have a large number of change requests because you never quite deliver what the customer needs.
- You don’t have much or any test automation, or your test automation is all GUI based.
- You have a large (and growing) number of bugs found by testers that never get fixed.
- Bugs are generally not fixed in the same sprint that they are found.
Okay so maybe some of those signs are true for you. How do you change that? What is this agile testing thing you need to start doing?
Agile testing is a mindset. It’s as different from traditional testing as Scrum is from waterfall. Through running several workshops we’ve distilled the mindset down to 5 key principles.
- Agile testing is an activity not a phase, it happens right from the start
- Agile testing is about preventing bugs rather than finding them
- Agile testing is a whole team responsibility, not just the responsibility of the tester
- Agile testing is about building the best possible system for your users, not trying to break the system developers built
- Agile testing is about critiquing the product as fit for purpose rather than checking that it matches the specification.
We all know mindsets are hard to change, and this is no different. What are the benefits of moving to a more agile testing approach?
- You can save time and money by preventing bugs rather than only finding them at the end, by involving testers right from the start of the process.
- You can have happier more engaged employees by getting rid of error prone and boring manual regression testing, by having your testers and developers pair to create automated regression tests.
- You can delight customers by making sure you aren’t just building what they asked for, but also something that will add value for them.
- You can improve your team’s velocity by removing test bottlenecks and fixing defects immediately.
I usually come across two classes of workitems in agile projects as I train, consult and coach clients at VersionOne.
- Class A workitems: Customer-driven or user-driven stories, features, epics, business initiatives
- Class B workitems: By definition, everything else. Several examples are listed below:
- Defects fixing work: Defects pushed out from earlier sprints, or reported by users in their production environment while the current sprint work is going on.
- Porting work: For example, port software from IP v4.0 to v6.0, port software from the existing database system to a different database system, port software to support multiple browsers, etc.
- Spikes: Proofs of concept, prototypes and experiments to reduce the technical risk and gain knowledge
- Develop test suites: Develop automated or manual test suites for various non-functional system-wide requirements, such as performance tests, usability tests, security tests, inter-operability tests, scalability tests, availability tests, system tests, etc.
- Run test sets: Run test suites (automated or manual) for various non-functional system-wide requirements listed above; run manual or automated regression tests sets; log defects found along with steps to reproduce the defects.
- Architecture runway work: Technical infrastructure design and coding effort necessary to support upcoming features in the nearer-term without excessive, delay-causing redesign. This type of work is becoming increasingly important as agile projects scale up. For further details, see the SAFe web site.
- Infrastructure work: Set up or improve development, test, build environments; continuous integration server; continuous delivery (DevOps) systems, etc.
- Dependency management work
- Online help, tutorials, release notes
- Technical debt reduction work
- Customer support team training
- General Availability (GA) release packaging
Often Class B work may represent as much as 30% of the total work if it is fully accounted for and properly estimated. For so-called hardening or stabilization sprints, all work is Class B work. However, Class B workitems are often not properly inventoried and logged in the agile application lifecycle management (agile ALM) tool; they are poorly estimated and poorly planned. Consequently, they come back and haunt the team during sprints as unplanned or underestimated work – sort of their revenge for not receiving the respect they deserve. These two classes of workitems are compared and contrasted in Table 1.
Treat all workitems as pretty swans deserving your full attention
No workitem should be treated as an ugly duckling. Here are several concrete steps I would like to recommend so you can treat all workitems as pretty swans:
Ownership: If the product owner is reluctant to own or support Class B workitems, or does not have a good understanding of them, team members should have an honest discussion with the product owner about the reasons, cost and benefits of Class B workitems. The discussion has to be along the lines that if we don’t take proper care of Class B workitems, the team will continue to increase its technical debt and end up lowering productivity in the future. In fact some Class B work (such as defect fixing and running test suites) even has impact on users. On the other hand, if we spend reasonable effort on Class B workitems (10% to 20% in our view), it will lay the foundation for productivity growth in the future. If necessary, senior management (perhaps facilitated by the ScrumMaster) may need to play a constructive role here, as there is never-ending pressure to deliver more and more Class A stories demanded (or thought to be needed) by customers and users.
Inventory and Visibility: There must be a full and proper inventory of all Class B workitems. They need to be logged into the agile ALM database with clear and complete description along with appropriate acceptance criteria.
Analysis: The analysis methods for Class A vs. Class B workitems are different. The product owner or business analyst explains and clarify Class A workitems. Team leads (development leads, QA testing leads) and other subject matter experts clarify various Class B workitems. Analysis of both Class A and Class B workitems should be done preferably one time-box ahead of their design and development time-box, as explained in my sprint pipeline blog post. Only with proper analysis effort can one clearly understand what needs to be done for each Class B workitem — the prerequisite for estimating, planning and the actual implementation effort.
INVESTment: Class B workitems also need proper INVESTment. They need to be independent of each other (at least the specification level). They should be negotiable between the product owner and the team, with both sides coming to an agreement on the scope of the work and what is outside of the scope. Although the value for some of the Class B workitems (such as spikes, architecture runway and technical debt reduction) is not immediately relevant to customers or users, the product owner needs to understand this work is important to reduce the technical risk and to improve the productivity (velocity) of future sprints. The team members should be able to break down large Class B workitems into smaller Class B workitems that can be completed in a single sprint. Each workitem needs to be testable.
Acceptance criteria and acceptance tests: Class B workitems must have acceptance criteria as agreed upon between their owners and the team, with concurrence from the product owner. Depending on the nature of the workitem, acceptance tests may be a matter of going through a checklist (for completion of release packaging or training the customer support team). Or it may be running and passing test sets, fixing, verifying and closing defects, checking that the spikes have produced the desired technical information (or if you’ve run out of the allocated time for the spike), online help is reviewed to match with working software, etc.
Estimation of effort: This creates challenges for Class B workitems. The practice of estimating Class A stories in story points using Planning Poker or the Table-top estimation method is quite common. But what about estimating all Class B workitems? Relative size estimation is a powerful technique, but it needs to be applied to stories of the same or comparable type so you can do a sensible apple-to-apple comparison in estimating relative sizes. If you compare relative sizes of disparate types of workitems — such as comparing stories with defects, stories with porting work, spikes with technical debt reduction, or test automation with training/online help — the comparison and resulting story point estimates will not be very meaningful. This is one of the reasons why some teams don’t bother to estimate Class B workitems, which is a mistake, as explained above.
I suggest that a team simply estimate the work effort for each Class B workitem in ideal hours, either based on the team consensus or based on estimation by experts in the team who are likely to do that specific workitem, such as a spike, porting work or online help. Many Class B workitems do need specialized expertise and it makes sense for the team member(s) to do that work to estimate it. This is a more appropriate way to estimate the effort than using relative size estimation to compare non-comparable workitems (it would be analogous to comparing apples to oranges or comparing apples to other objects like tires or stones).
Once a Class B workitem is estimated in ideal hours, it is very easy to convert that estimate into normalized story points by dividing the estimate in ideal hours by the Normalization Basis chosen by the enterprise, as explained in Part 4 of my blog series on the topic of Scalable estimation and Normalization of story points.
Normalized story point (NSP) = Estimate in ideal hours / Normalization Basis
For example, if the Normalization Basis is chosen to be 20 hours for an enterprise, then a defect estimated to take 4 hours to fix, verify and close is equivalent to 4/20 = 0.2 NSP. A spike estimated or budged to take 30 hours is equivalent to 30/20 = 1.5 NSP. And a porting effort estimated to take 120 ideal hours is equivalent to 120/20 = 6 NSP.
All Class A story points are also converted into NSPs as described in detail in my blog series on the topic of Scalable Estimation and Normalization of Story Points.
Now all Class A and Class B stories will have the same scale for expressing their estimates, i.e., normalized story points. This will make all story point math, reports, and metric meaningful and accurate.
Planning: Sprint planning must take into account both Class A and B workitems. After analysis and estimation steps, planning involves making sure that the planned work is consistent with historical velocity or available capacity. Let’s say the team has exhibited a stable average velocity of 25 (normalized) story points over the last 3 to 4 sprints comprising of both Class A and B workitems. Then under the so-called “Yesterday’s Weather Model” (same team members, same technology platform, same application domain, etc.), the team should plan on undertaking about 25 normalized story points worth of work (comprising of both Class A and B workitems) in the upcoming sprint being planned. If the Yesterday’s Weather Model is not applicable, the team will need to do capacity-based planning considering how the team capacity will be used to perform both Class A and B workitems. The product owner should rank-order the entire sprint backlog of both Class A and B workitems using the ranking method of his or her choice.
Status of Workitems: As all workitems of Class A and B are treated on the equal footing as explained above, all workitems are pretty swans. There should be no ugly ducklings. Planning, execution and retrospectives will all benefit from this approach. And the teams, projects and organization can only benefit.
Do you have any ugly ducklings in your agile project backlog? Can you think of any ugly ducklings that are not included in the Class B workitems list? Remember that ugly ducklings often have a disruptive effect on the well-planned work for pretty swans. Ugly ducklings can turn pretty swans into ugly ducklings, too.
Do resolve to treat all your workitems (both Class A and B) as pretty swans. From your team’s successive sprint retrospectives, your team should be able to judge whether the problems caused by ugly ducklings are going down steadily, sprint by sprint; if not, what corrective actions must the team take? Many corrective actions are presented in this blog (see the concrete steps presented above). In short, avoid the pretty swans vs. ugly ducklings dichotomy.
No one likes service interruption or downtime, especially when there is no clear explanation of what is going on and when systems will be operational again. While Assembla’s strives to provide 100% uptime (currently 99.98%), things happen which is why we have set up http://status.assembla.com.
Assembla’s new status page allows you:
- See the health of all Assembla services - our web application, repositories, and API
- See server response time and historical uptime
- View incident reports for explanations of outages and expected recovery times
- Subscribe to downtime alerts and incident reports via email, text, webhooks, and RSS
While we will still use twitter for communication, our new status page provides a more granular view of our services with the ability to subscribe to real time communication. Go check it out at: http://status.assembla.com.
We work with other people in office environments. Software development teams represent connected pulsating nodes of energies and emotions, regardless of whether the people stay in cubicles or in open spaces. As an outsider walks in to an office of some company, they might be able to sense it right from the start, if the emotional climate is moderate and comfortably mild, as in Northwest Pacific, or if there’s a sense of hidden tornadoes and storms in the air, as in the Plains, or if there’s a scorching drought and ruthless heat as in Arizona or in California. If you’re a softdev professional who is considering a job opportunity, you might want to make sure that your “climate” preferences match that of the company you’re going to commit yourself to. Some people don’t mind staying on the verge of storms, they even like it. Some prefer to stay away from the emotional extremes, expressed outwardly or latently. These preferences do not define someone as a competent or incompetent professional. It’s just that professionals need the environments that are right for them to show their best qualities in action.
We all know how challenging the situation with natural environment is these days. They launch initiatives to reduce the carbon footprint and to dampen the impact that industries are making on the climate. The damage from tornadoes, droughts and floods is just too costly, and not only in terms of damage to properties, but in terms of the count of lives taken. It’s very evident on the scale of the planet Earth, how dangerous the consequences of careless human actions can be.
It might not seem as evident and as dramatic, if the emotional atmosphere in an office feels like an accumulation of burnouts (think drought), or like forming a tornado’s supercell, or like a hopeless swamp. But, in the long run, the consequences for companies can be quite dramatic. Naturally, these emotional climates are created by people. If you’ve worked in several companies, you must have sensed that, and you must have felt if this particular environment lets you thrive, or if you want to get out from there.
Every sensible human being needs to take care of herself, first of all. On planes, the in-flight security regulations tell us: “Put on your oxygen mask first, then help the others.” Indeed, we can only deliver our best performance in an environment that suits us most. Some people do not want to make a difference in their career, and they want to work in a swampy company, in some monotonous many-year project, doing their 9-5 work, collecting their paycheck, and then going home. There’s nothing wrong with it, if they do their job well in this environment, and if the environment lets them live this way. Probably such people invest their energies into things that are unrelated to their work, e.g. their family or their hobby. They do not perform well under duress. If you’re the one who wants to stay away from burnouts, and if “work is the highest priority” is not your motto, then wanting to be hired by Google, for example, wouldn’t look like a sensible decision, considering accounts of Google’s employees working crazy 60-80 hrs per week. You’d need to pick a company with a more conservative structure and well-defined job boundaries and responsibilities. Well, drought-stricken companies might offer a better pay, but being lured with more $$$ only to lose your sleep and health wouldn’t be a wise personal strategy in the long run.
Then, if you’re the kind of person who truly wants to make a difference and contribute to some remarkable software product or service, you either need to start your own company or a start-up, or join a team of aficionados. You will hate to stay in a swampy boring environment if you’re a person like that. You would probably want to contribute to your company on many levels, beyond your initial responsibilities, if that’s the way you are, and you wouldn’t be happy in an environment that blocks your vigor and candor. In that case, you’d welcome this drought of drive and passion.
Some companies keep the climate somewhere in the middle between super-drought and super-swamp. In fact, those two might even co-exist, right by each other’s side, in one and the same organization. Some employees don’t feel that what they do makes a huge difference, and they don’t know what “passion for work” stands for. They just work. The others, however, might be staying in the drought climate zone, exposed to stresses, tensions and passions. Some risky decision-making might be involved, or meeting an important deadline, or winning over an important client. The problem then — and that’s when tornadoes are born — is when the drought-stricken individuals are passing on their second-hand stress to those peaceful “farmers”. Being a peaceful farmer in a software development company is not a bad thing per se, and you can be proud if you’re the one. Such farmers are usually the rainmakers, and drama is the last thing they need to do their work well. Burned out, impatient aficionados crave the rain in the form of a successful release, or meeting a deadline, but the rainmakers might be scared away by the aficionados’ stressed out behaviors. It might even make sense to put on some sort of blends on the farmers and intentionally guard them from the tense vibes. Catching a second-hand burnout does no good to organizational productivity; that’s why keeping the harmonious environment for the rainmakers should be high in the list of priorities for someone in a position of power. Balancing between a swamp and a heat is vital for such a company to avoid devastating tornadoes. In fact, the real tornadoes are formed when the areas of high pressure and low pressure in the air collide. The second-hand panic and anxiety is poignant, and emotions are not just emotions. They transform into productivity, fueling it or blocking it. So, the more anxious someone is to whip the horse, the more this horse would refuse to draw the cart. There’s a certain slight boundary where too much passion turns into restless anxiety,which burns out everything and everyone around.
I wonder, if it’s a coincidence that the company run by Bill Gates, the well-tempered, balanced person who stays healthy in his late 50′s, is headquartered in the gentle moderate climate of Northwest Pacific?
Many years ago my wife and I had a nice dinner at Petrossian in Manhattan, so when I got in my mind to
have a nice dinner a few weeks ago I decided to go back. “Sir”, I said to the waiter, after reviewing the menu, “Can I please have an appetizer of your Royal Ossetra caviar, the steamed Dover sole and, being quite thirsty at the moment, a bottle of your Champagne Louis Roederer Cristal 2006?”
“Certainly”, he replied, “all excellent selections”.
“Oh, one more thing”, I said, “I’m on a corporate expense account and can’t really
have any unseemly expenses. Can you please only charge me around $40?”
“But the champagne alone is about six times that!”, he said, looking a bit agitated.
Now I’m gobsmacked. “This is absolutely, without exception, my Minimal Viable Meal. When I came to the restaurant, I was looking for something extraordinary, and only these menu items will do the trick.”
“Well sir”, he replied, summoning up the composure of his full 26 years in the job, “might I suggest the
Seared Long Island Duck Breast and a glass of our iced tea? While not exactly what you asked for, I think
you would find it quite enjoyable, and very close to the budget you have for the meal.”
I pondered. The initial value proposition that had attracted me was an extraordinary meal in opulent surroundings. This might work even if it wasn’t exactly what I’d envisioned.
A Minimal Viable Product, or MVP*, is:
“A product with the fewest number of features needed to achieve a specific objective, and users are
willing to “pay” in some form of a scarce resource.”
In this case the duck was an effective fit for my objectives. Building a product with the minimal set of
features to meet a goals is a valuable end in itself. We write code and build features in order to enable
outcomes and long-term impact, but the software itself has no value. Software requires maintenance, support and training. The less you have of it, the better. Powerful as that is, there is more value provided by an MVP. When you build the “fewest number of features needed to achieve a specific objective” you also benefit from a rapid learning loop. No matter what you think is true of your customer - what they want and what they will do with the product you build - it will only be proven to be true (or false) when your product is in their hands. The sooner they get it, with the least amount invested, the sooner you’ll find out if your product ideas are right.
Additionally, if you focus on the critical few features first, then you are more able to respond
effectively when unexpected circumstances arise. And finally, if you run out of time or budget, you are more likely to have something you can ship if you’ve focused on the features that constitute the MVP first. A story map is a powerful tool for identifying those critical few features but that’s a topic for a future post.
*Cooper, Brant; Vlaskovits, Patrick (2010-10-15). The Entrepreneur’s Guide to Customer Development: A
cheat sheet to The Four Steps to the Epiphany (p. 40). Cooper-Vlaskovits. Kindle Edition.
Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.
The post My Minimal Viable Meal (Or The Value of a Minimal Viable Product) appeared first on BigVisible Solutions.
I’ve often seen new teams try to write detailed user stories for every feature in a release before it really makes sense. The reason you adopt agile is that you expect to learn through experience. When you write all your user stories up front, you may have stories that need to be discarded because new things you learn invalidate stories you’ve written. The time that you have the least information to write detailed requirements for an initiative is at the beginning, since that is when you have the least amount of knowledge about both the problem and the solution. As an initiative proceeds, you get feedback on your work, and that feedback influences the next stories that you write.
My advice is to write just enough detailed user stories to get started, and then do regular story elaboration throughout the product development lifecycle.
Now this advice goes counter to a need that many teams have - they are expected to know if they will deliver all of the requested functionality by the end of the release. There are two parallel approaches to this:
- Rough estimation using story points - best guesses without really having detailed acceptance criteria or
- Work on the stories that represent the highest risk / value first, learn more about your product, then write up the remainder of the stories and estimate them
Learning and designing by doing (Iterative and emergent design) is an effective technique for managing risk and getting you on the best path to a successful product. Writing all your stories up front is a path that often leads to waste and one that will ultimately slow you down.
Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.
The post The Risk of Writing Too Many User Stories Too Early appeared first on BigVisible Solutions.
An agile organization is able to rapidly notice and effectively respond to extreme change while shaping the future in the midst of that extreme change. Without that capability an organization is like a swimmer caught in a raging river, unable to control where they going, flailing their arms to avoid crashing against the endless parade of rocks. Organizational agility arises, and is most effective, in organizations that deliberately work to put it in place.
There’s a lot contained in this statement. In this blog post I’m going to cover “rapidly notice”. Future posts will cover the remaining parts.
Noticing what is happening in the world, with your customers and the markets you serve and within your company is a critical organizational capability for agility.
The information you need to orient yourself in a rapidly changing world is distributed. Your sales people get information from your customers as do your customer support representatives. Your customers discuss your products and your competitor’s products on social media. Industry trends, challenges and ideas are presented online, in journals and at conferences. Your staff, at all levels, have ideas for improving your existing product or creating new products. Analytics within your products themselves provide clues to how your customers interact with those products and respond to your innovations.
In an agile organization, people realize that information is an essential element for the success of the
organization and that the success of the whole is enabled by the speed at which information and meaning
moves across organizational levels and boundaries. Information is shared online, through communities of
practice and through planning events that bring people from multiple levels and disciplines together using
large-group facilitation techniques. It is part of how people work. To be a successfully agile organization, you need the processes, tools and culture of information collection, curation and sharing. Of these culture is the most important. Tools are helpful, but they can only enable a culture to share – they don’t cause it.
Sharing cultures are enabled by safety and attention. Safety is important because sharing often takes place in public forums. Executives openly sharing information, publicly showing curiosity and an interest to learn establish a powerful model for the organization to follow. When they interact with people across the whole organization, not just people on the leadership team, as peer learners, they help break down the barriers to the free flow of information until this becomes a core part of the fabric of the organization. Attention is equally important. Attention means simply that people pay attention to what is shared asking questions and adding to the conversation, This provides positive feedback both for the person sharing information and others who might share in the future. Attention isn’t simply an online phenomenon. Attention is people participating in communities of practice, it is executives sitting down with a team to learn from them. Here too executives can set the tone. If they pay attention it helps create a culture in which others do too.
To summarize, you can’t be an agile organization if you don’t know what’s happening with your customers, your competitors, your market and the larger ecosystem in which you operate. Your organization has broad and deep information that can enable your agility, but only if that information is available and it is given attention. For this to happen, organizations must create that capability through tools, practices and culture. In the next entry I’ll address the next part of organizational agility – turning information and learning into effective action.
Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.
The post Paying Attention: A Critical Capability for Organizational Agility appeared first on BigVisible Solutions.
Is your business breathing down your neck? Are you being told that you "aren't releasing new software fast enough" and that your "development teams need to deliver more value"?
Markets move fast. Disruption is everywhere. Innovation and customer satisfaction matter more than ever, and the pressure is on to deliver value faster. It's not enough simply to be proficient with Agile development; to deliver more value faster, you need to coordinate work across multiple teams and align that work to the business' top priorities.Agile Program Management: The Sweet Spot
Rally calls this Agile Program Management, and it's the sweet spot for achieving better-performing teams and better business results.
What does this sweet spot look like? Here's a glimpse:
- You have a high-performing program "teams of teams" that consistently delivers the right features on-time.
- You have a business culture that values collaboration, fast feedback, and rapid decision-making.
- You have a high degree of employee satisfaction.
- You can respond to market threats and opportunities with confidence and resiliency.
- Your business agility puts you ahead of, rather than behind, the curve.
Have you tried tooling software for the program level and found it ineffective because you didn’t change your development teams’ behavior or culture? Have you brought in ad-hoc coaching services only to discover that they don’t provide technical support or help your leadership team get visibility into the work being done? Have you weighed the cost of investing in an approach that gets it right against the cost of failure if you get it wrong?
Through our experience partnering with organizations of all sizes and maturity levels, Rally has established a proven approach for accelerating software value delivery. Our solution combines the right software with expert services to help you scale your Agile execution and deliver program-level value.
Rally Program Launch: Fast, Predictable Results
The Rally Program Launch solution provides the software, coaching, and training services you need to launch scaled Agile programs -- and deliver the right products and features to market, with speed and predictability. With Rally Program Launch we’ve helped customers see 2-4x faster time-to-market and millions in new revenue, with results in as little as three months.
Rally Program Launch uses a phased, Ready-Sync-Go approach to help you scale Agile practices and transform your development organization for responsive and sustained value delivery.
Through each phase, Rally provides all the consulting, coaching, technical, and training services you need to develop critical program-level leadership, gain organizational support, and establish the processes needed to plan and coordinate work across teams aligned to your portfolio priorities.Ready
- Build cross-functional Agile program leadership and launch a “team of teams” to deliver business value in alignment with business priorities
- Empower your teams with Rally Portfolio Manager, purpose-built software that connects strategic priorities to development execution
- Help teams create a program backlog aligned with business vision and objectives
- Develop a realistic roadmap and release plan that maximize value delivery to customers
- Level-set Agile development teams and help them collaborate across teams and timezones
- Give teams experience with operating in a synchronized cadence of iterations
- Launch your program with full delivery team participation at a facilitated Agile program planning session
- Support the program through its first program increment, ensuring delivery of working software
- Following the first program increment, coach the “inspect and adapt” planning sessions
Digital Globe’s 300-person program planning eventGet It Right
“Leaders and employees see the ability to change and adapt as the key to long-term success. They do not fear or avoid change; they embrace it because their ability to manage change well is their primary advantage.
“Perceiving the value of constant change is only the first step. Translating that perception into productive action requires know-how, processes, infrastructure, and resources. Leaders must commit the organization to a new course of action, mobilize resources, and implement changes.”
- “The Agility Factor,” Booz & Company
Rally can help you change into an organization that delivers more value, faster. We’ll help you get started, get there fast, and get it right. This is what we do so well -- you might say it's our sweet spot.
Too often we get caught up in the madness of the world and forget about all the little things that make life great. We have created a set of small cards for you to use with your team, or anyone in your life, to show your appreciation.
I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.Maya Angelou
Print them out on different colour paper and cut them up – then surprise someone.
Suppose a team identifies that they got blocked by a dependancy. One of the dependent teams didn’t deliver their part of the work, and so the team couldn’t complete their user story.
Now the team has to figure out what action they can take to reduce the likelihood of it reoccuring in the future. Some ideas come up like:
- Follow up more frequently with the team
- Escalate the issue to their manager
- Explain to the team how important this story is
- Escalate the issue to the team’s PO
- … and so on
Here, the team is directly addressing the problem and coming up with possible solutions.An alternative way using 5 Why technique
Now, suppose instead of solving the dependency issue directly, the team tries to find the root cause. The way to do this is to repeatedly ask “Why did this happen?” for each level of the cause that is uncovered. This is how such a discussion might go:
- What happened?
- We were blocked because of a dependent team that didn’t complete their part of the work
- Why did this happen?
- Well, they got the request too late and didn’t have time to stop their other work and complete it
- Why did they get the request so late?
- We didn’t know about the dependency until we started working on the story
- Why didn’t we know about the dependency?
- We had not groomed the story before hand
- Why didn’t we groom the story before hand?
- The PO didn’t have the story ready at that time
- Why didn’t the PO have the story ready?
- We didn’t have visibility on the plan for the release
- Why didn’t we have visibility on the plan?
- We didn’t do any release planning
So the root cause here is that the lack of release planning caused a chain of events that eventually led to a dependency blocker problem at the sprint.
The place that this team really needs to concentrate on is on doing a good release planning. If they do this, then it will eventually reduce the blockages due to dependency with other teams.The goal of the retrospective
The example above shows the difference between tackling issues at the surface level vs solving the root cause. As long as the team focuses on how to manage a mid-sprint dependency, they are not going to solve the issue. They will keep getting this problem again and again in the future, since the root cause is not addressed.
Also, it initially seems as if the solution is outside the scope of the team and there is nothing much that can be done apart from follow up and escalation. But the root cause is actually within the team and can be easily solved by the team themselves.
Finally, once we fix the root cause, we will have much fewer mid-sprint dependencies. The problem simply goes away for 75% of the cases.
A good perspective when tackling these kinds of impediments is:
Stop focussing on how to manage a problem, instead think about how we can prevent the problem from even occuring in the first place