Der Ausgangspunkt dieses Beitrags war eine Diskussion zum Thema Testautomatisierung und die Frage, wie deren Vorteile und Nutzen einfach kommuniziert werden können. Mit welchem Beispiel aus der alltäglichen Praxis lässt sich die Testautomatisierung für Software am besten vergleichen? Mir fiel folgender Vergleich ein: Ist denn die Testautomatisierung nicht eigentlich eine Versicherung für die entwickelte Software?
Aber der Reihe nach. Per Definition sind Versicherungen dazu da, ein mögliches Risiko für einen Schadenseintritt abzusichern . Da Software heute in vielen Unternehmen essentiell für deren Wertschöpfungsprozesse ist oder sogar die Wertschöpfung darstellt, ist deren Berücksichtigung für das Risikomanagement des Unternehmens nicht nur sinnvoll, sondern notwendig. Im Rahmen des Risikomanagements müssen mögliche Schadensfälle definiert und bezüglich ihrer Eintrittswahrscheinlichkeit und -schwere klassifiziert und priorisiert werden.
Stellt euch vor, dass das betrachtete Unternehmen 50% seines Umsatzes mit Hilfe eines Online-Shops erwirtschaftet und in diesem wegen eines Softwarefehlers mehrere Stunden keine Bestellungen getätigt werden können. Im realen Leben ein Worst-Case-Szenario, das immer wieder auch renommierte Shop-Betreiber trifft.
In der Lehre des Risikomanagements gibt es verschiedene Varianten, mit einem Risiko umzugehen. Das Risiko kann in Kauf genommen, minimiert, an Dritte übertragen oder gar vermieden werden. 
Viele Firmen entscheiden sich bei Software unbewusst für die erste Variante, da sie diese Schadensfälle gar nicht berücksichtigt, geschweige denn berechnet haben. Erst wenn der Schaden eintritt, wird sich ein Unternehmen seines ausgesetzten Risikos bewusst. Dabei wäre es doch so einfach, das Risiko mit Hilfe einer Versicherung auf ein akzeptables Maß zu minimieren. Diese Versicherung ist die Testautomatisierung. Mit Hilfe unzähliger automatisierter Tests werden regelmäßig alle wichtigen Funktionalitäten der Software auf ihre Funktionstüchtigkeit getestet. Diese Tests liefern somit regelmäßig Feedback über das aktuelle Risiko, das von der Software ausgeht. Mit Hilfe von Statistiken und Auswertungen können diese Daten dann in eine unternehmensweite Risikoüberwachung integriert werden.
Testautomatisierung sichert so nicht nur nachhaltig die Qualität und Wartbarkeit der Software, sondern verschafft auch ein Gefühl der Sicherheit, die eigene Software „im Griff“ zu haben. So let us start coding test driven!
 Wiktionary: http://de.wiktionary.org/wiki/Versicherung
 Ahrendts, F.; Martin, A.: IT-Risikomanagement leben! Wirkungsvolle Umsetzung für Projekte in der Softwareentwicklung. Berlin: Springer Verlag, 2008.
- Test Driven Development (TDD) und Scrum | Teil 1
- Der ScrumMaster ist eine Versicherung (Mike Beedle)
- Prioritäten | Product Owners Tools
Today, we are announcing a number of very exciting changes to Axosoft and OnTime, so lets get right into them:
- NEW V14.1 released – Tons of new features. Check out our “What’s New” page here.
- Axosoft and OnTime branding changes – We are dropping the “OnTime” name from our hosted product, but keeping it for our installed customers. Read more below.
- New pricing for Axosoft Scrum, Bug Tracker and Premium Support – Lots of exciting changes to pricing that you can read about below.
Since Axosoft was founded in 2002, customers often referred to the OnTime product line as “Axosoft.” Axosoft has become synonymous with providing best-of-breed Scrum, Bug Tracking, HelpDesk and Wiki tools for software developers, so when we separated the Axosoft OnTime product onto its own domain two years ago, OnTimeNow.com, the change didn’t make sense to a lot of our customers. Quite frankly we were slow to realize this ourselves. Two years later, we’ve come to the same conclusion: The “OnTime” portion of the product name is largely unnecessary, especially in the new cloud-centric world.
Now, rather than “Axosoft OnTime Scrum” or “Axosoft OnTime Bug Tracker”, the new names of our products are just “Axosoft Scrum” and “Axosoft Bug Tracker.” The entire set of products is just the Axosoft Product Suite.
This name change makes it easier to just say “we use Axosoft” when you refer to our dev tools. As a result of dropping the OnTime name, it also made sense to bring everything back under the Axosoft.com domain. So while your instance of Axosoft Hosted products will continue to work under [AccountName].OnTimeNow.com, they will also work under [AccountName].Axosoft.com. The Axosoft.com version is preferred as we expect to phase out the old name at some point in the future.Keeping the OnTime Name for Installed Customers
For our installed customers, we’ve decided to keep the OnTime name. This makes it easier to find your downloads, manage the OnTime Services on your servers, and any other dependencies you have built in your installed system that depends on the OnTime naming convention.New Pricing Changes
Lets start with a quick price matrix of the products that are affected by the pricing changes:
Of course, the most exciting pricing announcement is that we are making the Axosoft Bug Tracker just $1 per year (or free with any other product) for teams of any size. This is an unprecedented move by any developer tools vendor. Never before has a full-featured bug tracking product been made available as a hosted solution to software development teams for practically free. This is big. Imagine every software development team around the world having access to a high quality, feature-rich product for tracking their bugs and working together as a team. We fully expect that Axosoft Bug Tracker will become the de facto standard bug tracker for dev teams worldwide.So why are we doing this?
The why is easy. We love software and we want software developers to be able to create even better software. Tracking bugs is a fundamental requirement to creating great software products.
You might be asking yourself, “what’s the catch?” or “how can you afford to do this?” The answer to that is scale. We now have over 10,000 paying customers for our highly popular Axosoft Scrum software (as well as Axosoft HelpDesk and Wiki). This is a great way for us to give back to the community. Plus, something tells us that giving more development teams exposure to the Axosoft Product Suite through Axosoft’s near-free Bug Tracker will probably make our products even more popular than they already are. So while we do expect to benefit from the $1 Axosoft Bug Tracker, there truly is no catch for the customer. Buying Axosoft Bug Tracker for just $1 per year doesn’t put you on the hook for anything more!What’s the deal with the $1? Why not free?
There are two reasons for this: 1) We don’t want to get a zillion junk accounts that will never be used. A little skin in the game, even when it’s just $1, goes a long way to ensure only interested parties apply. 2) Collecting even a nominal fee of $1 gives us the opportunity to support new software startups with a new $10,000 grant program. We love software companies and this grant program gives us an opportunity to support new software startups with both money and mentorship that they badly need to build new products.Wait, I’m paying $7/user for Scrum or Bug Tracker, is my price going to change?
No. If you have Axosoft Scrum at $7 per user, even though we are raising the price to $10 per user, your price will remain the same $7 per user that you have been paying. Also, if you only have Axosoft Bug Tracker and were paying $7 per user for it, we kept your price the same, but added Axosoft Scrum at the same rate because the $1 bug tracker no longer has burndown charts and other features that are specific to Scrum. By adding Axosoft Scrum and keeping your price the same as before, we make sure you don’t lose any features and your price is unaffected.Can I change my configuration to downgrade to just the Bug Tracker for $1/year?
Yes, absolutely. Any existing customer can modify their account through the Tools Menu -> Account Administration.
The real lessons in software development come from production. The more frequently you can deploy – more feedback you can generate
- Software Design 21st Century by Martin Fowler http://t.co/6Fb3hQMV6X
- Programming Laws and Reality: Do We Know What We Think We Know? | Dr Dobb’s http://t.co/iUy3k9mxFj
- Rob Myers experiences with TDD – An open letter to the Editor in Chief of Dr. Dobb’s http://t.co/61zJtpx5xg
- Workflows of Refactoring – slide deck by Martin Fowler http://t.co/j3MyjFcsbp
- Rocket Powered: A Ranty and Dogmatic Troll Masquerading as Coding Guidelines http://t.co/pUSUvcE3Zq
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!
Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.
OpenSSL, the open source cryptographic library reported the Heartbleed vulnerability on April 7, 2014. The vulnerability allows stealing the information protected, under normal conditions, by SSL/TLS encryption.
We have had no evidence that this vulnerability was used against Sprintly but we have taken all necessary precautions to ensure the continued safety of your information.
Actions We Have Taken
- Within hours of the official report from OpenSSL, we patched and verified all our servers for CVE-2014-0160.
- We use Amazon’s ELB product for load balancing. They patched our region a few hours before we patched our servers.
- We have re-issued new SSL certificates to all our servers.
- We have rotated all of our SSH, Chef, and AWS API keys throughout our infrastructure.
- We have rotated all 3rd party API keys we use to provide services, such as Transloadit (file processing) and Postmark (email).
- We have set up our Chef nodes to re-key themselves every 24 hours. We suggest you do the same.
- Friday night we flushed all active sessions. This means you will have to log into Sprintly again when you get back to work Monday. Apologies in advance for any inconveniences.
You may consider taking these additional precautionary measures on your Sprintly account:
- Change your Sprintly password
- Reset your Sprintly API key
Both settings may be found in the Profile menu under your Gravatar.
Again, we have had no indication that this vulnerability was used against Sprintly but do feel that it is a good habit to keep your passwords and security keys regularly updated.
If you have any questions or concerns, please feel free to contact us at email@example.com.
An example Feature Card
The above card shows some typical elements:
- Card Color: Using a simple color priority scheme (e.g. red, yellow, green) can help teams decide the order of features to work on based on their priority in the backlog or any dependencies that exist between them.
- Title: In this case “Jump”.
- Description: Very often written in a User Story format. This briefly describes the feature from the point of view of the user, such as the player .
- Acceptance criteria: While planning an iteration, teams will capture some unique aspects of the feature that will need to be tested. For example, it might be important to the product owner that the blending of animations be smooth and without popping. Someone, usually a tester, will write this criteria the back of the card to remind the team to test the feature to ensure there is no popping while jumping.
- Start and End Dates: It’s useful to capture the day when the team starts working on a feature and when it’s done. As mentioned in the article about Feature Boards, it’s not best to work on too many features in parallel during an iteration. Using the dates will allow a team to measure how much work in progress is occurring during the iteration. I’ll describe how this is used in an upcoming article on Feature Board Burndown Charts.
- Estimates: As a part of iteration planning, each discipline will discuss the plan for implementing their portion of the feature and may want to capture some time estimates. Some teams use hours, some days, while some teams will skip estimates altogether. Capturing discipline estimates rather than individual estimates increases collaboration among members of the same discipline. These estimates are used to track whether an individual discipline is at capacity or not while features are planned. For example, if a team is finding that the sum of all animation work across all features adds up to more time than their one full-time animator can handle, they’ll find another animator to help them or they’ll change which features they commit to.
- Tasks: Tasks captured during planning or during the iteration can be annotated on the card with smaller post-its or, by using larger cards, be written on the cards themselves. If you use post-its, make sure you use the brand name ones with the good glue!
- Card Size: Feature cards are usually written on a 3x5 or 4x6 index card.
VariationsThe sky is the limit on how to format these cards. For example, some teams record the story points or t-shirt sizes on the cards and don’t use time estimates. Some teams will break down larger features into sub-features and track the completion of those. The key is to collect meaningful metrics that are part of an ecosystem to help the team better plan, execute and deliver features at ideal quality.
NextWe’ll look at an optional burndown or throughput tracking chart.
Most agile teams, when starting out new on their agile transformation road, conduct all sprint related activities in the same timebox, i.e., sprint planning, sprint execution, sprint review and sprint retrospective. This is illustrated in Figure 1, where each sprint (from Sprint 0 through N+1, represented by each row) is mapped onto a single sprint timebox (Timebox 0 through N+1, represented by each column), and successive sprints are executed in successive timeboxes in a sequential order (Sprint 0 in Timebox 0, Sprint 1 in Timebox 1, and so on).
Figure 1: Sequential execution of sprints
For example, all implementation tasks for Sprint 2 (analysis, design, code development and unit testing, acceptance test case development and acceptance testing, defect fixing – done concurrently (not as a mini-waterfall) by a self-organized, cross-functional team — are completed in Timebox 2. Sprint 2 planning is completed (before Sprint 2 starts) in approximately 4 hours for a two-week sprint (or 8 hours for a four-week sprint); and sprint review and retrospectives are completed in approximately 1 hour each for a two-week sprint (or about 2 hours each for a four-week sprint).
Each light pink vertical thin box separator between two successive sprint timeboxes represents a small timebox to complete all these ceremonies, i.e., sprint review and retrospective for the previous sprint as well as sprint planning for the next sprint. Thus all these tasks for successive sprints are carried out in a sequence of successive timeboxes. This is a simple and straightforward model where work goes in each timebox sequentially, sprint by sprint, without any overlap.
What are the advantages of and the challenges for the simple model of sequential sprint execution shown in Figure 1?
Advantages of the sequential sprint execution model:
1AS. Simple to teach, understand and learn – and hence covered by all agile text books, training courses, and certification programs.
2AS. Conceptually simple to execute — but fraught with challenges as explained below.
Challenges for the sequential sprint execution model:
1CS. Analysis issues may block the team and reduce throughput: Analysis of backlog items (or stories, as they are often called) must involve intense conversations among the product owner and team members, and confirmation of each story by defining its acceptance criteria. Stories can be properly understood only through conversation and confirmation parts of the story metaphor of card, conversations, and confirmation. The product owner should answer the questions and clarify the issues raised by the team members before design and code development work can start. This goal – clarifying all stories to reach a collective, common, shared understanding – may become very challenging if all stories are analyzed during the same timebox in which they are scheduled for design, code development, testing, defect fixing and delivery. This is so because the product owner may not know all the answers to team members’ questions without consulting users, customers and stakeholders, and performing necessary market and customer research and analysis. This entire analysis effort is often difficult to compress in the same timebox when design-development-testing-defect fixing work is also going on concurrently because the actions of many actors responsible for providing answers to the analysis questions may be beyond the control of the product owner (for example, some stakeholders or customers may not be available to provide specific clarifications within the timebox time constraints). The net effect of this challenge is often reduced team velocity (throughput) as the team is still waiting for stories to be clarified while sprint execution is going on, and team members may be even blocked waiting for clarification. Finally the sprint timebox may be over before some planned stories could be completed by the team members and accepted by the product owner.
2CS. Sprint planning may be less effective and efficient: Without clear and shared understanding of each story by all team members and the product owner, the team will find it difficult to estimate the work effort and complete all sprint planning tasks in the allocated time for sprint planning (approx. 4 hours for two-week sprints and 8 hours for four-week sprints). Needless to say poorly planned sprints contribute to poor (ineffective and inefficient) sprint execution and reduced throughput.
A better model to overcome the challenges of the sequential sprint model is to execute sprints in a pipeline fashion as illustrated in Figure 2, where the Analysis task is performed one timebox ahead of the Design-Code-Test timebox for each sprint. For example, development and analysis of Sprint 2 backlog is performed during Timebox 1 (one timebox ahead of Timebox 2), while the actual design, code development and unit testing, acceptance test cases development and testing, regression testing and defect fixing tasks for Sprint 2 are performed in Timebox 2. This same pattern repeats for each sprint, i.e., the work for each sprint proceeds in a pipeline manner, and as a consequence, the work for each sprint is spread over two consecutive timeboxes in an overlapping manner with the next sprint.
Figure 2: Sprint pipeline
What are the advantages of and challenges for the pipeline model of sprint execution shown in Figure 2?
Advantages of the pipelined sprint execution model:
1AP. Analysis work proceeds smoothly without blocking the team: As analysis work is carried out one timebox ahead of design-development-testing-defect fixing work for each sprint, the stories are substantially clearer by the time the team enters the Sprint Planning Workshop for each sprint. Note that the product owner has a full sprint timebox (typically 2 to 4 weeks) to consult with the necessary users, customers and stakeholders in order to answer team members’ questions on stories. And while this clarification of stories for the next sprint is going on, the team members are not held up or blocked as they are implementing the stories for the current sprint. Effort estimation and other sprint planning work proceeds more smoothly and can be more easily completed during the Sprint Planning Workshop.
2AP. Team experiences higher throughput with well understood stories and well-planned sprint: Note that although each sprint work is spread over two timeboxes (as shown by the blue oval in Figure 2), the throughput is not adversely impacted because the team is still delivering working software at the end of each timebox. In fact, as sprint planning effectiveness and efficiency goes up and stories become clearer, there is a lot less uncertainty about stories as the sprint starts, which reduces impediments, improves team morale and dynamics, and improves team’s throughput compared to sequential execution of sprints.
Challenges for the pipelined sprint execution model:
1CP. In each timebox, the team needs to work on two sprints: Although most of the time the team is focused on design-code development-testing-defect fixing work for the current sprint, some of its time must be set aside to analyze the backlog items prepared by the product owner for the next sprint. This is indicated by the red oval in Figure 2, where the team is spending most of its effort on design-code development-testing-defect fixing for Sprint 2 in Timebox 2, while at the same time spending some effort in analyzing the stories for Sprint 3. Some teams — especially when they are new to agile — may find working on two sprints in the same timebox challenging.
2CP. Small risk of doing wasteful work: There may be a small risk of analyzing few stories one timebox ahead of their actual implementation that may end up not being part of the next sprint commitment due to change in priorities as the next sprint planning is completed. Some people may even object that doing analysis one timebox ahead of the actual implementation could be somewhat wasteful, and it goes against the “just-in-time” agile work philosophy.
I will now explain how to deal with both of these challenges, 1CP and 2CP.
Solution to the challenge of working on two sprints in the same timebox (1CP): The ScrumMaster for the team can help manage work on both sprints in the same timebox (i.e., design-development-testing-defect fixing work for the current sprint as well as analysis of backlog items for the next sprint) by establishing and following a Sprint Cadence Calendar as illustrated in Figure 3.
Figure 3: Two-Week Sprint Cadence Calendar
The two-week Sprint Cadence Calendar has 10 work days, with workday starting at 8:00 AM (0800 hours) and ending at 5:00 PM (1700 hours). The team should allocate about 30 minutes for preparation for the Daily Scrum (DS) meeting and actual attendance by each team member. These DS meetings should be held every day of the sprint at the same time and place. In Figure 3, these DS meetings (preparation and actual meeting) are shown as starting at 9:00 AM and ending around 9:30 AM every day. If you are interested in understanding and implementing highly effective and efficient Daily Scrums, please take a look at my Making-daily-scrum-meetings-really-effective-efficient blog on the subject. The other ceremonies (Sprint Planning, Sprint Review, and Sprint Retrospective) are also illustrated in Figure 3. If you are interested in understanding and implementing really effective Sprint Retrospectives, please take a look at my Making-sprint-retrospectives-really-effective blog on the subject.
As shown in Figure 3, I recommend that the analysis of backlog items for the next sprint should be scheduled on a regular cadence, where a two-hour meeting is held on every Wednesday (3 PM to 5 PM), as an example. In these two meetings in a two-week sprint (a total of 4 hours or approximately 5% of the time in the two-week timebox), the product owner and the entire team converse about each story and also confirm each story with its acceptance criteria. If the product owner cannot answer some questions in the meetings, he/she has adequate time left in the two-week sprint timebox to get those questions answered in consultation with users, customers and stakeholders, without blocking any team member.
I also recommend that the product owner grooms the product backlog and prepares a draft of backlog items for the next sprint on a regular cadence, shown on every Tuesday (3 PM to 5 PM) in Figure 3. The cadence or pattern for sprint planning, sprint review, sprint retrospective, analysis for the next sprint, and product backlog grooming (shown in Figure 3) is for illustrative purposes only. Your team should discuss and experiment various sprint cadence options to find the cadence that most suits your needs and choose the cadence that best works for you. For example, a team may hold Sprint Review and Retrospective for the previous Sprint on Week-1 Monday morning (9 AM to Noon) followed by Sprint Planning Workshop for the current sprint from 1 PM to 5 PM. Another team may start the Timebox on a Wednesday (instead of Monday), and two weeks later end it on a Tuesday (instead of Friday), i.e., stagger the start and end of the timebox shown in Figure 3 by two work days to avoid Sprint Planning, Sprint Review and Sprint Retrospective falling adjacent to a weekend day (and tempting some team members to miss them due to their long weekend vacation!).
Regular cadence for all the activities mentioned above minimizes coordination, scheduling and transaction costs; increases predictability through a disciplined schedule published ahead of time for several release cycles (6 to 12 months), and helps an agile team to become a well-oiled machine. Regular cadence or pattern also reduces unplanned, unexpected, interrupt-driven work that is very damaging due to sudden, unplanned context switches with resulting loss of productivity.
For all these activities shown on a regular cadence in Figure 3, the ScrumMaster working with the team members must set aside adequate capacity: 4 hours for sprint planning, 4.5 hours for 9 Daily Scrum meeting (preparation and attendance), 4 hours for Analysis of the next sprint, 3 hours for Sprint Review, Sprint Retrospective and Celebration – a total of 15.5 hours of capacity is needed for each member for these activities, and that capacity for each member is not available for the design-development-testing-defect fixing work for the current sprint. If you are interested in calculating the agile capacity of a team after allocating capacity for all these activities, please see my Agile-capacity-calculation blog on the subject.
Solution to the challenge of managing the risk of doing wasteful work (2CP): An important reason why teams fail to deliver stories or backlog items in a sprint is that they were not understood properly when they were committed to the sprint plan during Sprint Planning. As Dean Leffingwell explains in his Agile Software Requirements book (page 211), from a timing perspective there are three opportunities to do this conversation and confirmation for each story.
- Prior to the sprint: This is what I have advocated in this blog by stipulating to engage in this conversation and confirmation only one timebox ahead. Doing it more than one timebox ahead will increase the risk that some of those stories may not get into any sprint commitment as they get trumped by higher priority stories, or they may be removed from the product backlog altogether due to changed business conditions.
- During the Sprint Planning Workshop: This workshop is limited to approximately 4 hours for a two-week sprint. In this short time box, the team has to not only converse and confirm the stories, but do story effort estimation and all other tasks related to sprint planning. The team may find it difficult to get the time needed to complete the conversation and confirmation for each story, or the product owner simply may not have answers to some of the questions and most likely there is no time in the workshop timebox (only 4 hours) to get the answers by contacting users, customers and stakeholders.
- During the actual sprint: If the team feels sufficiently confident that conversation and confirmation about a story can wait until the actual sprint due to uncertainty about the story’s business needs, then the conversation and confirmation for that story may be completed along with its implementation in the actual sprint if the story is of sufficiently lower priority. However, keep in mind that the story was committed to the sprint during its sprint planning without proper conversation and confirmation (and hence with either no estimate or a very rough estimate). This situation carries some risk and is not ideal.
I recommend that you complete the analysis of as many high priority stories as possible one timebox ahead of the sprint in which they will be implemented, try to complete as much analysis as possible for some of the lower priority stories during the Sprint Planning Workshop, and leave very small number of analysis questions to be resolved during the actual sprint if you have to.
In my coaching engagements, I have seen agile teams transitioning from sequential sprint execution model to the pipelined sprint execution model after 2 to 4 sequential sprints under their belt, and then with experience (inspect and adapt) getting better at the pipelined model. This is kaizen (continuous improvements) in work, resulting into higher throughput, improved quality, and increased team morale and work satisfaction.
Have you tried the sprint pipelined model? What is your experience?
Are you interested in starting your own sprint pipeline?
I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).
From life, dental, and accident insurance to Medicare supplements and annuities, the Physicians Mutual family of companies has spent the last 100+ years building nearly $3 billion in assets and consistently earning high ratings for its financial strength.
The Enterprise Technology Group (ETG) at Physicians Mutual is responsible for strategic and portfolio planning as well as project budgets, managing a portfolio of both Agile-driven and traditional project-driven work. So when it decided to go Agile in 2012, it wanted to choose a solution that would unite strategic and financial planning across multiple business units, and bring visibility and efficiency to its development work.
The PPM/ALM solution provided by the Rally and Planview partnership gives Physicians Mutual an end-to-end portfolio management platform -- from intake, to planning, to execution, to delivery. By connecting “above the line” strategy with “below the line” execution, the Rally and Planview partnership provides capacity and resource planning, strong financial reporting, and a holistic view of work regardless of project methodology.
“What attracted us to both was the partnership -- the two companies really partnered with each other in order to satisfy the customer’s needs,” says Joan Bohannon, Project Manager, PMO Operations, at Physicians Mutual.
Bohannon explains that the company has reached the point where mid-range planning is a key ingredient in helping teams understand what the strategic priorities are, and how those strategies break down into high-level features. “The teams then take those [high-level features] and look to figure out what it’s going to take to develop those features to the business.
“Without mid-range planning, we wouldn’t have any type of pulse on capacity to get those things done, nor any indication that we were working on the right things.”
"Mid-range planning has been very healthy for us.”
The Planview and Rally integration has brought Physicians Mutual a marked increase in transparency and an earlier assessment of risks. Other results:
- A 50% increase in major product releases year-over-year
- Substantial cost savings over three years from consolidating solutions and eliminating waste
- More products to market, faster -- from four major product releases per year to six, along with minor iteration releases
- Elimination of duplicate entries, meetings, and other process documentation along with efficiencies resulting in over 1,000 man-hours saved per year
- No more hours spent building reports to support financial analysis, accounting, and statutory reporting
- Increased visibility into work and resources, leading to better project management and risk mitigation
… no matter if it’s agile, Scrum, Kanban, SAFe, lean, XP or some mix of these methodologies.
Project managers want to track progress in any software development project, small or large. Sometimes they want to track progress not only in one, but in many projects at a time, and they want to be able to do this fast and conveniently. A timeline is a a visual management tool that helps accomplish this. Let’s take a closer look in which way.
Regardless of the software development methodology used, projects are meant to be completed. Always. However, at times project managers feel tied to by-the-book canons of Kanban (which is viewed by many as the best visual management system there is, but allows no time-boxing), or of Scrum (which has time-boxed iterations and releases but falls short with the visual part). What if a project manager wants to get the best both of Kanban, as a visual board, and of Scrum? Obviously, if projects have deadlines, one can not live by the classical pull and flow formula of Kanban only.
For progress tracking, Scrum allows only one visual report, called the burn down chart. When we want to keep an eye only on one project, such a report would probably be enough:
However, if many projects need a watchful eye of this one person, squeezing many burn down charts on one screen will not make the job any easier. Imagine how hard it would be to make sense of those charts arranged in a grid-like fashion. A project manager will likely want to see how projects correlate with each other, as it might be that the timing in one project affects the other projects. In this case, it would be sensible to drift away from the prescribed tool set of Scrum, and venture into the unknown land, fearlessly mixing sense of time (Scrum) with a neat visual representation (Kanban). That’s how this stylized mix looks as a timeline view for 2 projects (click to enlarge):
Work items in several projects on a timeline in Targetprocess 3
Such a visualization will fit a dozen projects into one screen, showing a project manager how all of them correlate with each other. This timeline has something more in store, than merely registering projects’ health in terms of time. Unlike in the burn down chart, one will be able to zoom in on any work item in any project and see what’s going on. This timeline bears a certain resemblance to Kanban board, because bugs, user stories and features are presented as cards stretched over time. At the same time, as in Scrum, the forecast will update depending on velocity (if one needs it done that way), and the timeline will show the latest status. If a project manager is in charge of several teams, that do several projects, this timeline will show when one can expect these projects to be completed:
A teams/projects timeline in Targetprocess3
User Stories inside Features on a timeline in Targetprocess 3
When someone pledges allegiance to Scrum, timelines offer a way to track progress with many iterations. Same for many releases, as opposed to clicking through single release and iteration plans one by one.
Tracking progress/status for several iterations on a timeline in Targetprocess 3
As we can see, it pays off when we forget about practices that seem to be rigidly prescribed by a methodology. A methodology is nothing, unless it works for our purposes, and helps us do the work better and faster. These timelines can not be, scholastically, classified as belonging solely to Scrum as a method, or to Kanban. While classical Scrum only offers burn down charts for progress tracking, this is not enough when people work with many projects and want to keep their hand on the pulse of all of them. Classical Kanban, in its turn, allows no time tracking as a methodology (and as a visual board). I’m not even sure if what they call “Scrumban” would accommodate this representation with timelines. Frankly, I don’t care how it’s called. I only care if it works for project managers or product owners, or any other folks in charge of projects, and helps them do their work well. And I wish that people were more of a freethinkers, unpinning themselves from the methodology labels.
Care to take a look where one can afford being a freethinker and still work as a project manager? With no strings attached to Kanban, or Scrum, sticking only to common sense and convenience of work? It’s here.
Jeff Sutherland observed that teams in the 95th percentile were 10 times more productive than average teams (50th percentile). He created Scrum to enable all teams to recreate those conditions that enable top performance.
How do you really get better performance from your Scrum team? It’s not about cracking the whip. That is usually counterproductive. It’s about creating the right conditions. In my Product Owner course, we look at the many tools available to Product Owner to enable better and quicker results from the development teams. On the saat-network company site, I have posted 12 tips (well, 13 actually) for how Product Owners can improve Scrum Team performance. Read the whole article...
Es ist Donnerstag. Böse Zungen sagen auch gerne mal Beraterfreitag. Aber das perlt ab.
Ich habe eingecheckt und befinde mich im Abflugterminal des Flughafens. In dieser speziellen Ausgabe von Flughafen hat sich ein besonders schlauer Fuchs gedacht, es sei geschickt, die kleinen gelben Automaten, an denen man Gefrierbeutel für den sicheren Transport 10x100ml hochexplosiver Flüssigkeiten erwerben kann, 20 Meter hinter der Taschen- und Personenkontrolle aufzustellen. Dann können die Passagiere die Flüssigkeiten, die sie vor dem Sicherheitscheck schon längst entsorgen mussten, endlich in die Plastiktüten packen. Toll!
Mein Tag verlief so lala – der Kunde wusste es mal wieder besser als ich und stellte mich dann gleich noch zusammen mit „dieser ganzen Beraterbande“ grundsätzlich in Frage. Widerstand zwecklos. Definitiv Grund genug, sich mit dem Gedanken an ein kühles Bier anzufreunden. Ich überschlage kurz das verbleibende Reisebudget und stelle fest, dass ich bei Verzehr eines Flughafenbieres wohl noch 4,50 Euro drauflegen müsste, da ich ja bereits heute morgen unbedingt das S-Bahnhof-Ciabatta und den korrespondierenden Kaffee beanspruchen musste. Mittags musste es dann selbstverständlich auch das Mittagsmenü der örtlichen Crossover-Kitchen sein, weil der Kollege, mit dem dieses eine superwichtige Thema besprochen werden wollte, eben dort schon einen Tisch reserviert hatte. Und das im schwäbischen Teil Baden Württembergs – also keine Chance, eingeladen zu werden.
Zurück ins Jetzt. Ich könnte natürlich auf ein kleineres Bier ausweichen…Naääh komm, das würde den Literpreis schlagartig dreistellig werden lassen. Außerdem ist heute Beraterfreitag. Ich entscheide mich für den halben Liter Weißbier vom Fass. Hmmm, wie es so schön in der Abendsonne schimmert, die hinter der Landebahn untergeht. Ich mache noch schnell ein Foto mit meinem inneren Auge und reiße sogleich der Bedienung den Kelch aus der Hand. Dabei verschütte ich etwas von dem kostbaren Gut auf den bereits klebrigen Tresen. Bin wohl nicht der erste halbverdurstete Hobbybierologe heute.
Da vorne am Fenster ist noch ein Plätzchen frei. Ich setze mich und hole meinen Laptop raus. Es ist noch etwas Zeit und ich überlege, einen kleinen Beitrag für unseren Blog zu schreiben. Thema: such dir was aus. Na gut, schreib ich halt was über Leute am Flughafen. Ha! Direkt neben mir hat jemand sein Bier nicht ausgetrunken. Das ist ja noch dreieurofünfzig voll! Also entweder, es war ihm wirklich egal, oder demjenigen ist wieder eingefallen, dass es ein Flughafen mit angeschlossener Kneipe ist und nicht umgekehrt. Oder ihr? Gibt es Frauen, die am Flughafen einen halben Liter Weißbier bestellen und dann die Hälfte zurücklassen? Unwahrscheinlich. Derart leichtsinnig sind doch bestimmt nur Menschen die es gewohnt sind, von einer Sekunde zur maximal übernächsten zu denken (das Bier im 30 Minuten später startenden Flugzeug ist kostenlos!).
Ein paar Meter weiter, eine Tafel: „Jede Pizza nur 10 Euro!!“ Wow, ich bin kurz davor zu Hause Bescheid zu sagen, dass ich im Begriff bin, das Schnäppchen der Woche zu schlagen und zu fragen, ob ich vielleicht noch eine zweite mitbringen soll. Ich schaue mich um, um zu sehen, ob sich dieser Anbieter eventuell in einem erbitterten Preiskampf mit unzähligen weiteren Pizzabäckern befindet. Natürlich nicht. „Do people at the airport know what the prices are at any other place in the world?“, fragte einst der amerikanische Comedian Jerry Seinfeld. Nun ja, ich habe vor ein paar Minuten ein Bier für 6,90 Euro gekauft – bin also Teil des Problems. Der randvollen Auslage nach zu urteilen hat die Pizza heute auch schon einmal 15 Euro gekostet und nun wird voller Enthusiasmus diese Wahnsinnsreduktion beworben. Ausgang ungewiss.
Gegenüber steht das Regal mit dem Zeitschriftenangebot der Airline. Eine Ausgabe des PLAYBOY mit jugendfreiem Einband – zu sehen ist das Bild einer verlassenen Karibikinsel in Häschenkopfform aus der Vogelperspektive – liegt dort aus. Und, was ist das? Ein Mittvierziger mit seinem maximal 10-jährigen Spross geht schnurstracks darauf zu, lenkt den Jüngsten noch kurz mit einer SportBild, auf deren Cover Manuel Neuer gerade irgendwen anbrüllt ab, um dann beherzt ins obere Regal zu greifen. Bold move, daddy! Was wohl Mama dazu sagen würde? Kriegt sie ja nicht mit. Und wenn doch, wird auch er behaupten, es ginge ihm lediglich um die super Reportagen.
Oh, der Flug wird aufgerufen. Für’s Priority Boarding habe ich noch nicht genügend Meilen – Anfänger! Aber ich habe noch etwas Zeit, um den Passagieren bei ihrer besten Engländer-Imitation zuzusehen und die restlichen 2,90 Euro auszutrinken. Nicht dass sich am Ende jemand über mein halb volles (!!) Glas lustig macht. Wie sie sich alle brav anstellen, obwohl sie doch noch laaaange nicht dran sind. Vielleicht sollte ich mal hingehen und darauf aufmerksam machen, dass sich die Sitzplatznummern auch in den verbleibenden 30 Minuten nicht mehr ändern werden. Und „ja, Sie werden mit sehr sehr großer Wahrscheinlichkeit der erste auf dem ausschließlich für Sie reservierten Platz sein“. Mich beschleicht der Verdacht, es könnte sich um traumatisierte Bahnkunden handeln, die auch Angst davor haben, nachts aus ihren Betten geschmissen zu werden, weil sie das „ggf. freigeben“-Schild einfach ignoriert haben. Ich beobachte das Schauspiel noch eine Weile und verpasse um ein Haar noch meine Boarding-Gruppe.
Im Flugzeug komme ich mit meinem Sitznachbarn ins Gespräch. Er erzählt mir davon, wie er aufgrund seiner Leibesfülle schonmal aus den komfortablen Sitzen vor den Notausgängen komplimentiert wurde. „Jaja, Alte, Kinder und Dicke haben keine Chance“, sagt er. Und ich weiß in dieser Situation nicht, wer mir mehr Leid tut: dieser arme Kerl, dem seine stattliche Physis so deutlich vor Augen geführt wurde, oder ich, der auf einmal mit der Hälfte des bezahlten Sitzplatzes auskommen muss. Ich versuche trotzdem, es mir ein bisschen bequem zu machen. Über die Lautsprecher hauchen Simply Red: „I wanna fall from the stars“ in die Kabine. Bei dem Gedanken an den Marketingmitarbeiter mit dem Einfühlvermögen einer Tiefkühltruhe, der tagelang gegrübelt und letztlich beschlossen hat, dass nur genau dieser der richtige Song vor jedem Take-off sein kann, lasse ich mich langsam in den Schlaf rütteln. Das kostenlose Bier werde ich natürlich verpassen.
Have you ever tried to act as a change agent in your company, and bumped into obstacles that seemed to be blocking the change? There’s no such software development organization in the world that allows no space for some sort of adjustment. Whether you hit a dead end as a change catalyst, or succeed will mostly depend on the following:
If the change you have in mind is trending — agile adoption can be a good example — then you’re lucky. One will have to apply little effort, because agile has gone mainstream, and there’s lots of information out there as to why and how agile is supposed to be good for a company. In this case, your intrinsic motivation as a change agent syncs with the extrinsic sweeping wave. Not only your organization, but many others will find it easy to jump on the same bandwagon. The change will then happen smoothly as in a domino effect, started by one easy move of a finger. With each new organization adopting agile, the chain extends to embrace more and more companies.
The second scenario for driving change is quite the opposite one. It might be related to a not that obvious trend, but you somehow feel that the way stakeholders treat this thing is in need of a major overhaul. This scenario involves repeating it over and over again that the product that your company develops needs to have a more intuitive user interface. You’d run into inertia as the stakeholders would probably say that all is fine with the user interface, because customers seem to be content with what they have, and revamping “the face” of the software involves some heavy changes in the code, etc. Unless you have some compelling proof that current customers and prospective clients find the user interface confusing, or even walk away, the effort required to boost the change in the attitude by pushing it down the pipe would be akin to that of a weightlifter doing 3 consecutive clean&jerk attempts.
The third scenario for driving change is not as easy, as scenario 1, and not as super-taxing, as scenario 2. It’s more related to an innovative change. Say, you’re still defending a difficult case, such as improving user experience in enterprise software. There’s no domino effect, and no “join the others” feel in the air. What can one do to trigger this change? How to convince the executives that the time will come when the current clients will not be happy with the bulky UI? The incentive for change in this case should be supported by good old research and analysis methods. Instead of tearing your muscles as with weightlifting (or, rather, breaking your tongue), one has to turn on the head and do a research, taking advantage of the big data that is, hopefully, available in any company, to make the need for a change appear compelling. If a hollow call to action is rendered into the language of pragmatism, the actual “raw muscle” effort of arguing wouldn’t take more than that of this little girl who uses the power of her opponent to win.
I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!
For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.
I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.
Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.
Agile Planning: it’s not an oxymoron.
On Tuesday, April 15, our TeamStart webinar series will answer your questions about Agile Planning. Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give good Q+A. We'll talk about making and keeping commitments, using tracking and metrics to predict delivery, and planning levels with time horizons.
Here are a few questions from past Agile Planning webinars:
- How does the product owner role fit into Agile Planning?
- Are there guidelines for setting up good planning estimates?
- If the team is not able to complete a story before the iteration ends, or if a critical change is requested, how do we respond?
From an Agile Planning perspective these are related questions. Let’s take a look at the answers to see why.1. How does the product owner role fit into Agile planning?
Answer: A product owner initiates and translates the product roadmap into a manageable product backlog. He or she participates in daily standups and manages the product dashboard. The product owner communicates with internal teams and the product manager, to understand the features and requirements and support the release planning and sprint planning exercises. It’s also the product owner’s job to allow the team to manage itself and understand Agile estimation approaches.
Answer: The principal guideline when estimating user story size is to employ a comparative approach. For example, rather than estimating in absolute terms, such as hours or days, you use abstract "story points" to compare the sizes of work items with past work the team has completed. Using an example the team is already familiar with helps you establish a baseline. By contrast, task size should be estimated in hours, since a task should be small enough that it doesn’t span more than a working day (about six hours.)
The estimation of stories done in abstract values happens continuously, and well before iteration planning; whereas task estimation is done once during the iteration planning meeting, immediately before the team votes to commit to the proposed work.3. If the team is not able to complete a story before the iteration ends, or if a critical change is requested, how do we respond?
Answer: When the scope of a user story becomes larger -- either because you underestimated its scope or because a change request comes in -- you should finish the current iteration as planned, and re-plan the remaining iterations in the release. In a situation where the team still has a fixed delivery date, you must work with the business to determine what other committed-to features or functions may be sacrificed to continue to work within the timebox limits. Teams should review burndown charts daily, so that you can spot problems early and mitigate them. When it’s necessary to re-estimate and re-prioritize features, you should signal to the business and stakeholders as soon as possible.
I bet you have at least three questions about Agile! Learn more about Agile Planning. Join Tuesday’s TeamStart webinar.Rob Ward
Im einem Projekt verlangte das Management für den kommenden Release, einmal zu schätzen, wie viele Bearbeitertage für die zu liefernde Menge an Funktionalitäten wohl benötigt würden, um einen Forecast abgeben zu können. Die Manager wollten das, weil sie mit der Storypointschätzung per Magic Estimation nicht zufrieden waren. Denn die sagte aus, dass das Scrum-Team bis zur Deadline bei der aktuellen Velocity von 40 Storypoints lange nicht das liefern würde, was eigentlich erwünscht war.
Alte Schule. Statt anzufangen, werden nun viele Arbeitsstunden darauf verwendet, vorherzusagen, wie lange es wohl dauern wird mit der Lieferung. Zeitverschwendung, so meine Hypothese. Zahlen aus 2012 belegen: 74% der IT-Projekte werden in der Zeit überschritten, 59% in den Kosten und 69%, was die Anzahl der gelieferten Features angeht. (Quelle: Standish Group 2013, S.2) Warum also viel Zeit auf die Schätzung verwenden, wenn wir immer wieder sehen, dass sie ohnehin mehr als ungenügend ist?
Ganz einfach: Die Schätzung wird verlangt. Punkt. Eines jedoch sollte die Erkenntnis aus diesen Erfahrungen sein: Lieber mehr Zeit für die Umsetzung verwenden als auf das stunden- oder tagelange Schätzen.
Natürlich gibt es in einem Unternehmen immer Interessengruppen, die Ressourcen und Kosten planen müssen. Aber uns sollte klar sein, dass wir unser „Geschätze“ der Dauer und unsere Methoden stark überdenken müssen. Vor allem auch die Frage, wer denn schätzen sollte. Im konkreten Fall entschied man sich dafür, pro Story und Thema den jeweiligen Experten die Dauer der erwarteten Arbeit schätzen zu lassen. Gefährlich, sage ich, und möchte hiermit auf das Buch „Die Weisheit der vielen“ von James Surowiecki verweisen. Darin behauptet der Autor, dass die Masse stets besser entscheidet als ein Einzelner: „Die Masse ist dumm, dumpf und gefährlich. Dieses verbreitete und von Wissenschaftlern gestützte Urteil ist falsch. Wahlumfragen, Pferdewetten, der Publikumsjoker bei Günther Jauch, Google oder Millionen Steuerzahler belegen: Die Menge entscheidet in der Regel intelligenter und effizienter als der klügste Einzelne in ihren Reihen. Ihre Problemlösungen greifen besser als die von Experten. Vorausgesetzt, jeder Einzelne denkt und handelt unabhängig, die Gruppe ist groß und vielfältig, und sie kann darauf vertrauen, dass ihre Meinung wirklich zählt.“ (aus dem Klappentext)
Prompt versuchte ich nun, Surowieckis Vermutungen in einem kleinen Experiment zu beweisen, um die Schätzweise im Projekt überdenken zu lassen. Ich ließ von jedem im Team schätzen, wie viele orange Bälle in dem Sack waren, den ich mitgebracht hatte. Die Wahrheit lag bei 101 Bällen. Das wusste außer mir jedoch niemand. Die kleinste Schätzung lag bei 50, die höchste (im übrigen von einem Experten für Zahlen) lag bei 150. Im Mittelwert schätzte das Team den Inhalt auf 96 Bälle. Ein beeindruckendes Ergebnis, das erstaunlich nahe an der Realität von 101 lag und die Theorie Surowieckis zumindest unterstützt.
Eine Gruppe von Menschen (je größer desto besser) schätzt immer genauer als der klügste Einzelne.
Genau das ist der Grund dafür, warum der Publikumsjoker bei „Wer wird Millionär“ in den meisten Fällen so zuverlässig funktioniert.
Auch dafür, warum eine Gruppe von Experten mit je nur einem Tipp es 1968 schaffte, den Standort des im im Atlantik havarierten U-Bootes “Skorpion” auf 75 Meter genau zu ermitteln.
Bei all diesen plakativen und hochinteressanten Beispielen erinnern wir uns daran, worum es geht: Mehr Zeit in die Umsetzung als in das aufwändige Schätzen zu stecken.
Bleibt nur noch die Frage: „Schätzt du noch, oder baust du schon?“
- …denn wenn Anna größer als Tom ist und Tom größer als Friederike…
- Die Weisheit der Vielen
The Internet was surprised recently by a bug in the OpenSSL software, called "Heratbleed," that might allow an attacker to see your HTTPS traffic including your password on a Web login form. You can read about some of the technical details regarding "Heartbleed" here and the OpenSSL 1.0.1g fix here.
We updated the Assembla servers to remove the vulnerability within a few hours of being notified about a fix. Our acceleration provider, Edgecast, had not yet updated their servers with the fix. This extended the time that Assembla users were exposed to the vulnerability for a few more hours. We had turned off Edgecast, causing some pages to render more slowly, until Edgecast's servers were updated. Everything has since returned to normal.Protect Yourself!
- It is recommended that you reset your Assembla password. You can do so using the password reset form.
- If you use API keys or tokens, we recommend that you reset your API keys or tokens.
- If you use the FTP tool, we recommend that you reset your server login credentials and update these credentials in Assembla's FTP tool.
If you have any questions or concerns, please do not hesitate to contact us.
One of the biggest struggles I’ve seen in organizations adopting Agile is in the area of Production Support. Every organization that has a product to support has to manage this. It’s a critical part of the business. There’s a lot of responsibility to manage a 24/7 Production environment. The middle of the night calls, working on code you didn’t create. Speediness, precision, reaction time and problem-solving are crucial.
The struggle typically comes in the form of pulling people away from active Scrum teams to make whatever hot fixes are necessary. This is clearly disruptive to the Scrum development team. Oftentimes, a team member is being pulled away to work on something that’s very unpredictable. Who knows how long they could be gone from the team; an hour, a day, a week? This disrupts our rhythm and velocity. It makes planning difficult. Team cohesiveness suffers. The person getting yanked to do the Production work usually isn’t too happy either. Context switching makes them less productive. And in the end, we actually get less done!
Alas, we need to get these ongoing high priority bug fixes out the door asap. And we need the ability to re-prioritize any time. We need focus. And we know that 2 week sprints aren’t a good fit.
So how do we combat this? How can we keep our Production environment up to speed, while also allowing our Scrum teams to develop that stuff they’ve committed to getting done for their Product Owner?
My preference, and one that I’ve seen work well in many organizations, is to create a new Production Support team that works these hot fixes as part of a Kanban effort. The only negative feedback I’ve heard on this is that it seems like punishment to some (think of the Gulag in Northern Syberia). To combat this feeling, we’ve tried cycling folks on and off the team so they don’t burn out. As any good Managers knows, it goes a long way to show your appreciation to this group in some way. Maybe a really nice work environment, new laptops, snacks/drinks, etc. A sincere pat on the back also works wonders. Get creative. Additionally, there may be some folks that don’t fit well in your new highly collaborative team culture. They’re very smart folks, but more of the lone wolf variety. This team could be a natural fit for them.
At the end of the day, technical debt is something that will keep us in this death spiral. We want fewer bugs in Production. In order to get out of it, we need to improve our technical practices, our code quality, our testing, our architecture, and our design. It’s hard to make any progress if we keep patching up something that’s not good to begin with. Sometimes it’s just easier in the long run to scrap it and start fresh (I know, that’s a hard pill to swallow).
How do you handle Production Support in your Agile environment?