Give a developer an app, and she’ll use it for a narrowly defined task. Teach a developer to build an app, and she’ll have the power to solve your toughest business challenges as they arise. In today’s fast-changing technology environment, that adaptability is powerful — and necessary. Hackathons are a great place to build that adaptability into your organization.
Participating in a Rally hackathon is like tailoring your favorite dress or suit. It adds a whole new dimension to your style. Take it in a little for the perfect fit. Add an extra hidden pocket. Accessorize with a pocket square to match your Chuck Taylor sneakers.
Just like a good suit, the software feels better and works better as you customize the fit. And once you start, new solutions appear to help with your changing needs.
From my experiences running several hackathons for Rally and other organizations, I’ve discovered that few events give you the sense of satisfaction you gain from this kind of event. I'm talking about the satisfaction of walking out the door having solved a complex problem in an amazingly fun environment.
On June 18 and 19, after the RallyON!™ 2015 Agile conference, we’re hosting a Rally Hackathon. As a developer, you’ll learn how to work on Rally’s App SDK to create custom visualizations and applications to get the information you need now — and the firsthand experience to build what you need in the future. We’ll pair each developer with a Rally engineer for two days of hands-on coding.
And if you like challenges, the winning pair will head home with the prized golden sombrero (and an Oculus Rift headset to match). We built some great apps last year and can’t wait to see what everyone creates June 18–19 in Phoenix, Arizona.Chase Doelling
I’m often asked how many user stories you should have in a sprint and how big is too big for a story. People are looking for guidance.Stories per Sprint
I’ve heard some coaches recommend “3-6 stories per iteration per developer”. That’s a bad rule of thumb. For a team of 7 developers you would have over 20-40 stories which is likely way too many. It also subtly takes the focus off of swarming and puts attention toward a developer per story.
5 to 15 stories per sprint is about right. Four stories in a sprint may be okay on the low end from time to time. Twenty is an upper limit for me if we’re talking about a Web team with lots of small changes to do. Twenty-five may be okay for maintenance teams knocking down a backlog of small defects, but that’s way too many for new development of actual user stories. If you can do that many, your stories are too big, your sprint is too big or your definition of done is too weak.
Most stories shouldn’t take more than half the sprint to develop and test. Having 1 story each sprint that takes more than half the sprint is all I would advise, and in that case all the other stories should be very small. For a 2 week sprint, it’s better if every story can be completed in 1 to 3 days. (Adjust that for longer sprints.)
I need to elaborate on that last comment: should be able to complete each story in 1 to 3 days. I’m often asked whether that’s the developers working independently or all together. The answer is “whatever you are doing today.” It is best if the team can swarm stories such that multiple developers can work on a story at the same time. If 2 or 3 devs can work on a story at the same time, then you can have larger stories finished within that 1 to 3 day rule of thumb. (And higher quality and better cross-training.) But if the team isn’t there yet, if that’s not the way they work today, then having stories that are too big given the way they are working is counter productive.Points per Story
What’s the maximum number of points for a story? How big is too big? How many points is too big for a story depends on the team’s pointing scale. I’ve known teams that start with 5 (5, 10, 15, 25, 40, and Too-Big). I’ve also known teams where a 1 point story would take less than half a day. For them, a 13 might not be too big. If a 1 takes more than a day, then 13 is probably too big. Generally, too big is an order of magnitude larger than the typical small story.
Here’s an example: Assume my 1 point story takes a day or two and once in a while we have something that is truly tiny and we call those half a point. The 1 pointer is my typical low end of the range. I have something smaller, but it’s not typical. A 13 is an order of magnitude larger that 1 point story. It’s very difficult to keep the scale linear when there is that much diversity in your story sizes.
People don’t buy what you do, they buy why you do it.
– Simon Sinek
Over the last few years I have come across the notion of an Agile Ecosystem and several different thoughts around what constitutes an Agile Ecosystem. I have seen people in the industry refer to the Agile Ecosystem as a number of practices used together to achieve a delivery team’s agility goals. For example, the marriage of Scrum, XP, DevOps and Kanban. I think leveraging the best of breed in all of these areas makes perfect sense. However, the Agile Ecosystem is much bigger and needs to support the business as a whole. To drive sustainable agility and continuous improvement, an ecosystem must be built and maintained at an enterprise level.
So… how do you go about building a high performing ecosystem that can provide value and continually delight customers?Start With Why
It starts with Why… In other words what are the business drivers for making the organizational transformation. Why are you transforming? It may be to increase your market responsiveness, improve quality or greater predictability. Whatever it is, it needs to be clear.
When the why is understood and transparent, the trek toward an agile ecosystem that supports the entire enterprise can begin. The trek starts with defining the end-state vision of your transformation and putting structure, governance and metrics in place to support the transformation.
When you have clarified why you are going through the transformation, the next step should include forming teams at the delivery, program and portfolio levels. Then setting up a clear governance model and a way to demonstrate measurable progress. When all of these things are in place, the journey toward enterprise agility can begin.
With the end-state in mind and a shared understanding of why, it’s time to get clarity on the team structure so governance and metrics can be applied. In my next post, I will touch on the teams in a scaled enterprise agile ecosystem and how they need to work together to deliver value to the customer.
SAFe is a marathon, not a sprint, and it can sometimes be fairly challenging, so who better to provide some tips than Dean Leffingwell, the creator of the Scaled Agile Framework® (SAFe®).
Here are seven tips I learned from the recent AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.”
In addition, there were more questions than we had time to answer during the live event. I’ve attached the Q&A here.
7 Tips We Learned about SAFe from Dean Leffingwell
1) We need a new approach, one that harnesses the power of lean and agile and applies to the needs of those building complex applications and systems.
The Agile Manifesto was developed for small teams, but it also applies really well to organizations that have scaled horizontally rather than vertically. There is an entire body of work on lean now, with dozens of books written by Don Reinertsen, Michael Kennedy, Alan Ward and others that are great books, but they’re mostly ethereal principles, not practice-based. When I think about SAFe, I think about codifying the things we’ve learned and turning those principles into practices.
2) This cannot be a bottoms-up movement that falls on the deaf ears of leaders and managers.
Management owns the system and is responsible for changing it. Lean and SAFe are leadership approaches. That’s an important statement about where the responsibility lies.
3) One of our bedrocks is the house of Lean. The house of Lean transcends the team. It’s a value system that’s very broad and has value at the top. It has pillars and it has leadership.
The SAFe Value System is drawn as a house for a reason. Value is most easily stated as achieving the sustainably shortest lead time with best quality and value to people and society. How do you make that work? One of the pillars is ”respect for people and culture.” We must understand that a change to an enterprise is a change to culture and a change to people.
4) Product development flow is a key part of what we described, as well as how to avoid the stop, start, stop, start, milestone, stop, post-milestone, start activity to deliver value continually.
Innovation: we have a brand new body of work from the lean startup community furthering relentless improvement, or the Kaizen mindset. Kaizen is a change word; it’s a word designed to get people’s attention and make them ask, “You say you are continuously improving, but are you relentless in that improvement? Tell me one problem you’re working on right now and tell me what tools you’re using to solve the problem.”
5) At the enterprise-level we’re literally scaling agile across the enterprise. We need leadership. It’s not optional.
The foundation of agile development is agile teams. We’re scaling agile, so we can’t treat the leaders as impediments or just pretend as though we taught the software development teams to speak Chinese and we didn’t bother to teach the leaders. That’s not going to scale.
6) If you’re talking about enterprise-level problems, you must apply systems thinking.
Optimizing a part does not optimize the whole. Only when you optimize the whole do you get the optimum result. Build incrementally with fast, integrated learning cycles. That’s the PDCA loop of Walter Shewhart and W. Edwards Deming; that’s what an iteration is.
7) We want the measures to be meaningful.
SAFe is focused on milestones that are based on objective evaluation of working systems. Measurements that help visualize, limit WIP, reduce batch size and manage queue lengths are the basic tenets of flow. A long queue of work means you’re slow and a long queue of committed work means that you’re predictably slow. Shorten the queue and you’re going to get faster. You don’t have to just cut code faster to get results faster; you just need to manage the queue.
I hope you found these tips as beneficial. As I said in the beginning, SAFe is a marathon, not a sprint. If you find yourself in a bind, don’t stress; someone has probably encountered a similar challenge and can provide a few helpful tips.
Interested in learning more? Watch to the recording of the AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.”
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.
I’m excited to share with you a tremendous moment in our company history. Earlier today, our Board of Directors approved a definitive agreement for CA Technologies to acquire Rally. I truly believe that this acquisition, once it closes, will be a great step forward for our company, and that CA is the right partner for Rally.
You can read the press release with more details here, but I’d like to take a moment to share a few thoughts.
This union will be about bringing innovation, expertise and global resources to our customers so that they can better disrupt their industries. Together, we will allow the most demanding enterprises to be truly agile, improving their ability to deliver high quality software to customers faster, and enabling them to respond to market changes more quickly and confidently.
While we’ve signed the definitive agreement today, the transaction is not closed or final, and won’t be until Q3 of this calendar year, assuming the completion of a tender offer, regulatory approvals and satisfaction of other customary closing conditions. That means that for the time being we are still operating as independent companies and will continue to focus on delivering great value to our customers and partners.
I want to personally thank the terrific community of partners, customers, employees and friends in the Agile community. Thank you for learning and innovating with us, and we are humbled by your support of Rally as we’ve evolved as a company. I’m excited about this next step on our journey and look forward to the opportunity ahead.
Cautionary Note Regarding Forward-Looking Statements
Certain statements either contained in or incorporated by reference into this document, other than purely historical information, including estimates, projections and statements relating to the business plans, objectives and expected operating results of Rally Software Development Corp., or Rally, and the assumptions upon which those statements are based, are “forward-looking statements.” These forward-looking statements generally include statements that are predictive in nature and depend upon or refer to future events or conditions, and include words such as “believes,” “plans,” “anticipates,” “projects,” “estimates,” “expects,” “intends,” “strategy,” “future,” “opportunity,” “may,” “will,” “should,” “could,” “potential,” or similar expressions. Such forward-looking statements include the ability of Rally and CA Technologies, or CA, to complete the acquisition of Rally by CA, including the parties’ ability to satisfy the conditions to the consummation of the acquisition and the possibility of any termination of the related acquisition agreement, timing of completion of the acquisition, the acceleration of growth of the combined enterprise and the transition of jobs, leadership and culture. The forward looking statements contained herein are based on current expectations and assumptions that are subject to risks and uncertainties which may cause actual results to differ materially from the forward-looking statements. Actual results may differ materially from current expectations because of risks associated with uncertainties as to the timing and completion of the merger; the risk that competing offers or acquisition proposals will be made; the possibility that various conditions to the consummation of the merger may not be satisfied or waived, including that a governmental entity may prohibit, delay or refuse to grant approval for the consummation of the merger; the effects of disruption from the transactions on Rally’s business and the fact that the announcement and pendency of the transactions may make it more difficult to establish or maintain relationships with employees, suppliers and other business partners; the risk that stockholder litigation in connection with the merger may result in significant costs of defense, indemnification and liability and potential delay; other risks and uncertainties pertaining to the business of Rally, dependence on individual customers, the impact of competitive products and pricing pressure; claims that Rally’s services infringe the intellectual property rights of others; the inability to enforce or protect intellectual property rights and proprietary techniques against infringement; the inability to maintain or attract key personnel; interruptions to Rally’s information technology systems; and other risks detailed in Rally’s public filings with the U.S. Securities and Exchange Commission (the “SEC”) from time to time, including Rally’s most recent Annual Report on Form 10-K for the year ended January 31, 2015 and Quarterly Reports on Form 10-Q. The reader is cautioned not to unduly rely on these forward-looking statements. The forward-looking statements contained in this document speak only as of the date hereof, and the Company expressly disclaims any intent or obligation to update or revise publicly these forward-looking statements, whether as a result of new information, future events or otherwise.
Notice to Investors
The tender offer referred to in the accompanying materials (the “Offer”) has not commenced. This communication is for informational purposes only and is not an offer to buy or the solicitation of an offer to sell any securities. The solicitation and the Offer will only be made pursuant to a tender offer statement on Schedule TO, including an offer to purchase and other related materials that CA intends to file with the SEC. In addition, Rally will file with the SEC a Solicitation/Recommendation Statement on Schedule 14D-9 with respect to the Offer. Once filed, Rally’s stockholders will be able to obtain the tender statement on Schedule TO, the offer to purchase, the Solicitation/Recommendation Statement on Schedule 14D-9 and related materials with respect to the Offer, free of charge, at the website of the SEC at www.sec.gov.
RALLY’S STOCKHOLDERS ARE ADVISED TO READ THESE DOCUMENTS, ANY AMENDMENTS TO THESE DOCUMENTS AND ANY OTHER DOCUMENTS RELATING TO THE OFFER THAT ARE FILED WITH THE SEC CAREFULLY AND IN THEIR ENTIRETY PRIOR TO MAKING ANY DECISIONS WITH RESPECT TO THE OFFER BECAUSE THEY CONTAIN IMPORTANT INFORMATION, INCLUDING THE TERMS AND CONDITIONS OF THE OFFER.
[introduction] Sharon wants to hear about conference sessions on women in tech that Diana attended.
[2:20] How do we prepare, recruit and retain diverse workforces?
[8:00] Did Diana learn anything new from these conferences?
[10:00] Blogger (see link below) Why is the Venture Capital/Silicon Valley world only looking for women engineers – we accept diverse experience from men, why not women?
[11:50] Diana was more impressed by the fact that sessions on diversity in tech were being held at all, than that they had anything especially new to say.
[12:30] Diana and Sharon’s session at the upcoming Agile 2015 conference – “Are We Doomed to Sticky, Tricky, and Icky? Men and Women in Agile.”
[15:00] Sharon recently facilitated a panel on “Tackling Gender Bias in the Workplace”.
[20:10] Gender bias has changed – it’s now more subtle, it has gone underground, and when it hits young women in the workplace it’s a surprise.
[21:45] For women, is humor a better teacher for men who need to gain awareness of their gender bias?
[25:05] Agile done well sets up a more collaborative workspace that is more in tune with people who are not into “macho” ideals.
[27:30] Sharon: “If I had a nickel for every time I’ve thought, ‘this was designed by a man, if a woman designed this they would know not to do this…'”
[28:15] The infamous wireless microphone made for people who wear pants with a back pocket and a button up shirt!
The New Soft War On Women, http://newsoftwaronwomen.com
It is fascinating to me how much work in progress most organizations have, how little they are able to accomplish, and the levels of stress that exists in these organizations. It is also fascinating to hear the responses you get when a suggestion to limit work in progress – “we can’t do less, we have to do all that has been asked, we can’t just work on one thing…”
Before I joined LeadingAgile, the business unit I worked in went through a program called the 4 Disciplines of Execution. At the core of this program was the need for an organization to focus. A compelling statistic from this program showed that organizations that focus on one goal for the year accomplish the goal. They are also able to accomplish their goals if two goals are focused on. Once an organization had three main goals for the year, the success of completion dropped to zero percent, zero.
The power of a few clear goals at the organization level is one in which there is alignment and a relentless focus on accomplishing those goals. We can also extend this concept to all levels of an organization. When we implement a tiered model for delivering value in the organizations that LeadingAgile works with, we use lean concepts to model flow and limit work in progress. Limiting work in progress creates organizational focus. A common refrain when we work with client is “focus on finishing work, not starting work.”
Taking this concept down to the delivery team, it is common, with new teams, that they are working very hard to complete their sprint commitments and some of their metrics indicate they are making great progress in getting their work done. But, teams can do this and still not deliver anything of value. Let’s look at an example of how this might happen.
A dashboard that many delivery teams use to determine if they are on track for completing their sprint commitments is the sprint burndown. When this is used to model the completion of story tasks you may see something like this:
This looks good! Right? The problem is that this doesn’t paint a full picture. Are we focusing on finishing work or starting work?
The other dashboard I encourage teams to use, especially new teams, is the cumulative flow diagram. I’m not going to dive deeply into the characteristics of this dashboard but I will focus on how this can be used to determine if we are focused on finishing. The CFD will show us the state of backlog items within the sprint. Not started (ready), in progress, in testing, done, accepted, etc. If we are focused on finishing then we want to limit the number of backlog items being worked on so we can get them finished as quickly as possible.
The following diagram is a situation where the teams are focusing on finishing work. The bands are narrow and things are moving from new to in-progress, to in-test, to done quickly. This is what we want to see:
Let’s take a look at a real burn down of a new delivery team. How can this team focus on finishing?
Uh oh! It is clear from this chart that the team quickly has all backlog items in progress within days of the sprint starting. The few developers on this team are working on all of the stories and are not focused on getting a backlog item into testing so it can move to done. In fact, this team didn’t get any backlog items completed for this sprint even though they were working hard. Also, who gets creamed in this situation?
The teams in this organization were coached on the use of the cumulative flow diagram and started using the rallying cry of “get to green”! Very quickly, their cumulative flow diagrams began to look like the example of a good CFD.
They fully embraced the concept of focus on finishing work, not starting work. If we encourage this behavior across the organization it evens out flow and increases throughput. I would encourage you to reflect upon the work that you have underway. Are you focused on a few and finishing or are you juggling so many balls that you are unable to get things completed?
Focus requires prioritization. What is the most important item to finish? Often that is a difficult first step. This was a critical piece of the Four Disciplines of Execution – determine what the most important goals are and have the organization develop an intense focus on accomplishing those goals.
In December, Rally announced its partnership with Code for America, the leading nonprofit organization that’s furthering the civic tech movement. From grassroots to global, citizens are collaborating with local governments, nonprofits, and community groups to use technology to solve problems and improve people’s lives.
Code for America believes that “government can work for the people, by the people, in the 21st century.” The civic tech movement is gaining momentum and needs more people to jump in and become citizen engineers. That’s why we’re bringing the civic tech experience to attendees at the RallyON!™ 2015 Agile conference, and we want you to join us.
By participating in Spark Civic Tech sessions, you’ll get hands-on and interactive experiences that will inspire you to get involved. You’ll learn techniques — from design thinking to using open data — that you can easily apply to your day job, too.
We’re offering a sampler consisting of two hands-on workshops, an interactive “spark talk” session, plus an intriguing keynote speaker to pique your interest and get you excited about what YOU have to offer by getting involved in civic tech in your local community. Check these out and if you haven’t already, register for #RallyON15.
- Build it! A Civic Hacking Workshop — Don’t be afraid. It’s as easy as putting together Legos. Anyone can do it ... with a good set of instructions and someone to guide you. Civic hacking is simply people working together quickly and creatively to help improve government and therefore, their community. By the end of this two-hour workshop, you’ll exclaim “I did it!” and see the results of how you’ve contributed to an existing app. Whether your coding skill level is novice, guru, or somewhere in between, sparks will fly. Get there early and bring your own laptop. Seating is limited. Monday June 15, 1:10–3:00 p.m.
Design Thinking Meets Civic Tech Workshop — If they don’t address problems that people truly want solved, products are destined to require push from the creator rather than generating pull from the user. But how do you uncover those wants to design a product that people will pull out of your hands? This question plagues every product owner. In this rapid-pace workshop, you’ll use design thinking to tackle a civic tech problem: how to get people like you — who understand how to increase organizational agility to mobilize people, process, and technology — involved in the civic tech movement. The workshop results will generate insights for Code for America and will teach you how to use design thinking to supercharge your everyday work. Tuesday June 16, 9:45–11:35 a.m.
Sparking Agility: Code for America Brigades — How do you help an all-volunteer civic tech team grow and thrive by implementing Lean startup strategies and Agile team practices? Rally’s partnership with Code for America is about taking on this challenge. Andrew Hyder will set the stage on the Brigade movement, which has more than 120 chapters across the U.S. Next, Rally’s Agile experts will share 7-minute Spark Talks on how working with their local Brigade has sparked some projects and practices to increase their agility. Monday June 15, 3:40–4:30 p.m.
Keynote: How is That Possible?! Sparking Agility in Local and Federal Government — Most people don’t use the words “agility” and “government” in the same sentence. But that’s changing. Come learn how in this session with Ryan Martens, Rally CTO, and Hillary Hartley, co-founder of 18F, an innovation lab within the General Services Administration that’s aiming to improve federal IT services. Ryan will talk about how Rally is partnering with Code for America to spark the civic tech movement and bring agility to municipal governments. Hillary will describe her experience scaling these concepts and using design thinking, Lean UX, and Agile methodologies to bring agility to — of all places — the U.S. government. Wednesday June 17, 11:00–11:45 a.m.
Project meetings are an essential part of every project engagement. It’s where project statuses get relayed, issues get discussed, assignments get reported on and clarified, and key group decisions are made. They must happen. And it’s really important that the key stakeholders are in attendance. You know the ones—usually your team, the customer and whoever else has more than a cursory interest in the project. If your key decision makers are skipping your meetings it can cause critical task or decision delays that need to be made immediately—not a week from now. Especially when you’re trying to be agile!
So why are people skipping your meetings? What is going wrong that is driving key attendees away? They should consider your project meetings essential, not optional. Let’s examine three potential reasons this may be happening…
You tend to accommodate the latecomers. Do you find yourself recapping everything for those meeting attendees who straggle in 10 or 15 minutes late every time? This can drive the rest of the attendees crazy and you may not be aware of it—until they decide to just skip the meeting altogether. Remember that everyone’s time is very valuable—not just yours. If you want to maximize attendance and productivity, you’ll need to look at the meeting from the attendees’ point of view, not just from yours.
Try this next time—don’t recap. When they arrive late tell them you need them on time as a courtesy to everyone already there and to help maximize productivity and minimize wasted project expense. Remind them that they are key players on the project and you need their participation. If it keeps up, go to their supervisor. Don’t threaten them with that though, just do it if it continues for the next couple of meetings.
You have trouble sticking to the agenda. You put out a nice agenda, but you have trouble staying true to it. That can be confusing to those in attendance and—if you sent it out in advance as you always should—it can really frustrate those who came prepared to participate on key points of the agenda only to see those things not even being addressed. It’s ok to add to the agenda during the meeting, but at least be sure to address everything that is on the agenda before straying. And only stray if you really have time to do so …see the next key point…
Your meeting time management skills are lacking. Are you starting and ending your meetings on time? If not, you have a tendency to lose people along the way. Their time is valuable and if they see you as a poor time manager, they aren’t likely to allow you to waste their valuable time for very long before they just start skipping your meetings. And that will be your fault, not theirs…so if you go to their supervisor complaining about their attendance, you will definitely get that negative feedback thrown at you. Start on time, end on time and stick to the schedule and topics. Do that and you’ll earn a good reputation as a meeting facilitator.Summary
Our project meetings are critical to our ongoing project engagement. It’s where we disseminate project information and make assignments. It’s where group decisions get discussed and finalized. Without them, it’s difficult to make progress. So use them wisely. And staying true to the points above will help keep key stakeholders in the meeting seats and productively contributing to your meeting’s and project’s success.
How about our readers? What meeting frustrations have you encountered …either as a meeting facilitator or an attendee? What’s most important to you when you’re heading to a meeting …what keeps you there week in and week out?
Occasional stories about Rally customers who are doing cool and interesting things.
Seagate is a big name in storage solutions, with a long list of innovations that have pushed the industry forward over the past 35 years. It’s also a big name at Rally. That’s because Seagate’s Firmware Engineering group has cracked the nut on enterprise scale Agile — a topic we eat, sleep, and breathe here at Rally.
Over the past few years, the Firmware Engineering group has transformed itself from an area that was “constantly under the microscope” — with inconsistent delivery and recurring defects — to a well-oiled machine delivering with higher speed, quality, and predictability.
I recently had the pleasure of speaking with some folks at Seagate who have been instrumental in driving this transformation forward, including Sr. Director of Firmware Engineering Dennis Rubsam and Sr. Engineering Manager Iky Chan (who moonlights as an Agile lead for the group).Why an Agile transformation?
According to Rubsam, it all started with one developer, one high-profile project, and a delivery date that kept slipping thanks to shifting requirements. Frustrated by the seemingly endless cycle, the developer on the project finally approached Rubsam with an idea: Scrum.
Instead of working with a monolithic set of requirements that was bound to change over time, he argued, developers could commit to smaller chunks of work, adapt as they go, and start delivering value sooner. The pitch worked; Rubsam took the idea and ran with it.From Agile Scrum to Agile at Scale
The Firmware Engineering group spent some time mastering Scrum practices at the team level, embedding Agile coaches into the teams, focusing on writing good user stories, and establishing a consistent cadence. The fundamentals, in other words. It was a good place to start, but Rubsam soon realized they needed to operate on a larger scale.
That’s when Rally started working with them, doing what we like best — helping organizations adopt enterprise scale Agile. The group embraced the Scaled Agile FrameworkⓇ (SAFeⓇ) and pulled the teams together into a release train. The aha moment came when the Firmware Engineering group started doing what we at Rally call big room planning.
Chan summed it up nicely, “We had to shift the mindset and big room planning sessions were a big part of making that happen. It forced us to build more discipline into our delivery.”
Today, the group has run nearly a dozen big room planning sessions, bringing quality assurance, the core technology group, and other functional teams into the mix.It’s a Journey, Not a Destination
The transformation is paying off for Seagate. With greater alignment and collaboration, the group is delivering faster, with greater predictability, fewer critical bugs, lower defect rates … and no more never-ending projects that fail to deliver business value. Which means the culture has improved as well. The best part? The group is in a position to keep growing and improving. We can’t wait to see what’s next on their journey.Learn More at RallyON
You can hear more about Seagate's transformation journey by reading the case study, or by joining us at this year's RallyON Agile conference in Phoenix, June 15–17. Seagate is just one of many organizations who will be there to share their experiences, approaches, tips, and inspiration. Explore the agenda to see specific sessions and register now to secure your spot!Jen Page
We talk about how change is happening faster than ever, but that doesn’t mean we need to push change via massive, top-to-bottom initiatives. We see it happening in far more dynamic ways, and so does Dan Pink, one of our exciting RallyON!™ 2015 keynote speakers.
Dan’s presentation, “The Cascade Effect: How Small Wins Can Transform Your Organization,” will cover the complicated nature of change, how it really happens in an organization, and why small increments can have a big impact — especially when it comes to delivering at the new pace of change.
Dan Pink is a recognized author of five provocative books –– including best-sellers in the New York Times –– but his influence extends well beyond his writing. As a speaker, he focuses on behavioral science and has delivered more than 1,000 lectures. Dan’s TED Talk, “The Puzzle of Motivation,” has garnered more than 13-million views.
Don’t miss this opportunity to think differently about how you can affect change within your organization and beyond. Register now for the RallyON 2015 Agile conference — three days of learning, inspiration, and fun with your peers and some of the brightest minds in the industry. Explore our agenda to view everything happening and you can even drill down by track to find the specific sessions that interest you most.
Hope to see you in Phoenix, June 15–17.Morgan Campbell
The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.
Product backlog refinement—sometimes called product backlog grooming in reference to keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.
During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog. The team is given a chance to ask the questions that would normally arise during sprint planning:
- What should we do if the user enters invalid data here?
- Are all users allowed to access this part of the system?
- What happens if…?
By asking these questions earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately.
If those questions were asked for the first time in sprint planning, and too many could not be answered, it might be necessary to put a high-priority product backlog item aside and not work on it during the sprint.
These questions do not need to be fully resolved in a backlog refinement meeting. Rather, the product owner needs only to address them just enough so that the team feels confident that the story can be adequately discussed during the coming planning meeting.
Backlog refinement in that sense is really a checkpoint rather than an effort to fully resolve issues.
I like to hold the product backlog refinement meetings three days before the end of the current sprint. This gives the product owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint are more suited to their cadence, and that is, of course, fine.
Unlike other Scrum meetings, I do not think the product backlog refinement meeting requires the participation of the whole team.
If you think about a whole team meeting three days before the end of the sprint, there is likely to be someone who will be frantically busy—someone who, if forced to attend one more meeting, may have to work late to finish the work of the sprint.
I’d prefer to conduct the meeting without such team members. As long as the same team members don’t miss the meeting each sprint, I think it’s fine to conduct backlog refinement meetings with about half the team plus the product owner and ScrumMaster.
It’s all too easy to take it a little bit easier during the summer, so we created a list of agile books to keep you on your toes.
Whether you read them at the beach on vacation or the back porch while the kids are at camp, you can rest assured that your agile practice will be a little bit better this fall.
We live in a world that is broken. For those who believe that there must be a more efficient way for people to get things done, here from Scrum pioneer Jeff Sutherland is a brilliantly discursive, thought-provoking book about the management process that is changing the way we live.
In this book you’ll journey to Scrum’s front lines where Jeff’s system of deep accountability, team interaction, and constant iterative improvement is, among other feats, bringing the FBI into the 21st century, perfecting the design of an affordable 140 mile per hour/100 mile per gallon car, helping NPR report fast-moving action in the Middle East, changing the way pharmacists interact with patients, reducing poverty in the Third World, and even helping people plan their weddings and accomplish weekend chores.
Woven with insights from martial arts, judicial decision making, advanced aerial combat, robotics, and many other disciplines, Scrum is consistently riveting. But the most important reason to read this book is that it may just help you achieve what others consider unachievable – whether it be inventing a trailblazing technology, devising a new system of education, pioneering a way to feed the hungry, or, closer to home, a building a foundation for your family to thrive and prosper.
The Project Management Profession is beginning to go through rapid and profound transformation due to the widespread adoption of agile methodologies. Those changes are likely to dramatically change the role of project managers in many environments as we have known them and raise the bar for the entire project management profession; however, we are in the early stages of that transformation and there is a lot of confusion about the impact it has on project managers:
- There are many stereotypes and misconceptions that exist about both Agile and traditional plan-driven project management
- Agile and traditional project management principles and practices are treated as separate and independent domains of knowledge with little or no integration between the two and sometimes seen as in conflict with each other
- Agile and “Waterfall” are thought of as two binary, mutually-exclusive choices and companies sometimes try to force-fit their business and projects to one of those extremes when the right solution is to fit the approach to the project
It’s no wonder that many Project Managers might be confused by all of this! This book will help project managers unravel a lot of the confusion that exists; develop a totally new perspective to see Agile and traditional plan-driven project management principles and practices in a new light as complementary to each other rather than competitive; and learn to develop an adaptive approach to blend those principles and practices together in the right proportions to fit any situation.
Scaled Agile Framework (SAFe) Distilled:
A Practical Guide to Scaling Agile in the Enterprise
By Richard Knaster and Dean Leffingwell
Today, companies know they must adapt quickly or die. They are increasingly seeking to adapt by using agile principles and practices – but many are still changing too slowly, and can’t sustain change. Fortunately, a growing number of enterprises have found a far more effective solution: the Scaled Agile Framework (SAFe).
SAFe changes the game by integrating Agile, Lean and product development flow thinking with a new operating model that successfully coordinate works at all levels: team, program, and portfolio. SAFe helps managers learn to become lean-thinking leaders, working with teams to continuously improve their systems, and create environments where everyone flourishes.
In Scaled Agile Framework (SAFe) Distilled, two SAFe pioneers show software practitioners how to use achieve higher productivity, improve the quality of their software processes, and bridge the divide between executives, managers and practitioners – aligning everyone towards common goals and objectives. If you want to scale and sustain agile in the enterprise, SAFe can get you there. Scaled Agile Framework (SAFe) Distilled will help you launch it, quickly earn value from it, and grow its value with every new project.
*Book description from Amazon
Agile Change Management:
A Practical Framework for Successful Change Planning and Implementation
By Melanie Franklin
The concept of agile working has been adopted by many organizations that recognize the need to respond quickly and easily to new opportunities in a world of complex and continuous change.
Agile Change Management offers best practice advice for planning and implementing change projects. Concrete tools help deliver projects successfully and realize benefits earlier on in the process.
By emphasizing and encouraging collaborative practices, the book illustrates how to build trust, influence and motivate others, and create a roadmap that outlines all the processes, activities and information needed to manage any type of change initiative. With advice for creating the right environment for change the book explains: who should be involved at each stage in the life style cycle, what tasks need to be completed at each stage, the concept of change in both large scale transformational programs and micro-level business projects, and the needs and benefits behind change strategies.
Along with a practical toolkit of materials available both online and in the book, Agile Change Management is essential reading for anyone who wants to develop the competencies of an effective change manager working in any project or program.
This book is certainly about software development management, but it is also a book about business. Managers can no longer afford to discuss these two topics independently. This book is meant to eliminate the seat-of-the-pants intuition and rough approximations that have been far too prevalent in software development management. The growing popularity of agile methods has shown that a healthy balance between strict process and individual flexibility can be achieved.
David Anderson takes it a step farther, and explains how the healthy balance of agility can help businesses become more profitable. The result is a book that will allow managers to foster teams that produce better software, less expensively, on time, and with fewer defects.
If you have tried to implement Agile in your organization, you have probably learned a lot about development practices, teamwork, processes and tools, but too little about how to manage such an organization. Yet managerial support is often the biggest impediment to successfully adopting Agile, and limiting your Agile efforts to those of the development teams while doing the same old-style management will dramatically limit the ability of your organization to reach the next Agile level.
Ángel Medinilla will provide you with a comprehensive understanding of what Agile means to an organization and the manager’s role in such an environment, i.e., how to manage, lead and motivate self-organizing teams and how to create an Agile corporate culture. Based on his background as a “veteran” Agile consultant for companies of all sizes, he delivers insights and experiences, points out possible pitfalls, presents practical approaches and possible scenarios, also including detailed suggestions for further reading.
If you are a manager, team leader, evangelist, change agent (or whatever nice title) and if you want to push Agile further in your organization, then this is your book.
Discover how to coach your team to become more Agile. Agile Coaching de-mystifies agile practices – it’s a practical guide to creating strong agile teams. Packed with useful tips from practicing agile coaches Rachel Davies and Liz Sedley, this book gives you coaching tools that you can apply whether you are a project manager, a technical lead, or working in a software team.
To lead change, you need to expand your toolkit, and this book gives you the tools you need to make the transition from agile practitioner to agile coach.
Agile Coaching is all about working with people to create great agile teams. You’ll learn how to build a team that produces great software and has fun doing it. In the process, you’ll grow a team that’s self-sufficient and skillful.
This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software. You’ll find chapters dedicated to introducing Test-Driven Development, designing retrospectives, and making progress visible.
Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In this book, Agile Alliance cofounder Mike Cohn discusses the philosophy of agile estimating and planning and shows you exactly how to get the job done, with real-world examples and case studies.
Concepts are clearly illustrated and readers are guided, step by step, toward how to answer the following questions: What will we build? How big will it be? When must it be done? How much can I really complete by then? You will first learn what makes a good plan-and then what makes it agile.
Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more. Highlights include:
- Why conventional prescriptive planning fails and why agile planning works
- How to estimate feature size using story points and ideal days—and when to use each
- How and when to re-estimate
- How to prioritize features using both financial and nonfinancial approaches
- How to split large features into smaller, more manageable ones
- How to plan iterations and predict your team’s initial rate of progress
- How to schedule projects that have unusually high uncertainty or schedule-related risk
- How to estimate projects that will be worked on by multiple teams
Agile development methodologies may have started life in IT, but their widespread and continuing adoption means there are many practitioners outside of IT – including designers – who need to change their thinking and adapt their practices. This is the missing book about agile that shows how designers, product managers, and development teams can integrate experience design into lean and agile product development. It equips you with tools, techniques and a framework for designing great experiences using agile methods so you can deliver timely products that are technically feasible, profitable for the business, and desirable from an end-customer perspective.
This book will help you:
- Successfully integrate your design process on an agile project and feel like part of the agile team
- Do good design faster by doing just enough, just in time
- Use design methods from disciplines such as design thinking, customer-centered design, product design, and service design
- Create successful digital products by considering the needs of the end-customer, the business, and technology
- Understand the next wave of thinking about continuous design and continuous delivery
*Book description from Amazon
Agile Project Management with Scrum (Developer Best Practices)
By Ken Schwaber
The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But Scrum’s simplicity itself—its lack of prescription—can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and failures—culled from his years of experience coaching companies in agile project management. Through them, you’ll understand how to use Scrum to solve complex problems and drive better results—delivering more valuable software faster.
Gain the foundation in Scrum theory—and practice—you need to:
- Rein in even the most complex, unwieldy projects
- Effectively manage unknown or changing product requirements
- Simplify the chain of command with self-managing development teams
- Receive clearer specifications—and feedback—from customers
- Greatly reduce project planning time and required tools
- Build—and release—products in 30-day cycles so clients get deliverables earlier
- Avoid missteps by regularly inspecting, reporting on, and fine-tuning projects
- Support multiple teams working on a large-scale project from many geographic locations
- Maximize return on investment!
Whether you’re brand new to agile or been practicing for years, there’s something for everyone on this list of summer agile reading. I hope the list has inspired you to continue your agile advancement this summer.
What other books would you recommend?
I have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public.
I find it difficult to release books in progress. The in-progress part challenges my perfection rules. I also know that some of you who want this book will wait until it’s done, or worse, available in paper.
However, since this is an agile and lean book, it seems nuts to not release it, even though it is not quite done.
If you get the book, please send me comments about what confused you, what you thought was crazy, and anything else.
Thanks so much!
In case you don’t remember the crazy gold rush days of the first dotcom boom, let’s just say that this was a defining image of the times:
At the time you could land a well paying job at pretty much any dotcom with no more than some basic HTML skills and a willingness to learn. A wave of people swept in and made up a large part of the dotcom workforce. Having a background actually programming was really nice to have, but became almost an afterthought as VCs helped push the rush to bring in warm bodies. If you were in another field at the time and wanted to try out life as a developer, project manager, tester, system admin it was a great time to jump in. There was low risk and plenty of reward.
I worked for a director who had been a bartender until 1999. On a project in 2000 one team had a former translator, an office administrator, and a lawyer. All of them had bootstrapped up on books and built a few static HTML sites before they found their first jobs as developers.
I noticed early on that the talent pool had completely dried up when I opened up an office for a dotcom in 2000 in Las Vegas. Our main office was in SF and I was amazed at the number of hires they’d made that really didn’t have any coding skills. Vegas at the time had a pool of solid developers, but we’re not Silicon Valley and the hometown university is UNLV. Still on average we were able to get better developers typically with real experience. I remember my first time visiting SF in 2000 and noting that 90% of all the billboards in the city were advertising doctors, many focused on recruiting. I’d never seen anything like it.
The bar was almost absurdly low for developer in the dotcom boom. This time the bar has moved up a bit. Now the default entry into the field is a Code Academy or Dev Bootcamp experience. Having survived the dotcom boom and bust I think it’s a good thing that the really junior dev coming from non-science or engineering backgrounds actually has done some real coding before starting their first job.
We’ve dipped our toes into these waters in the past year hiring two junior devs who had gone through dev bootcamps. We’ve been pleasantly surprised by several things that we didn’t get from junior developers in the dotcom days:
- They have pair programming experience
- They actually write unit tests without prodding or coaxing
- They understand that they’re on a steep learning curve and embrace it
- They don’t have a lot of bad ingrained habits
- They understand the basics of putting together a web site
- They are used to source control, commit early and often, and open source
So the new Dotcom 2.0 junior developers have a leg up from the early 2000s. I think more of them will stay in the field. They put some real time and effort into switching or starting a new career an possibly a decent sum of money and they’re more likely to stick it out. And their baseline is a lot better. They’re all feeling really underprepared even in their first paying dev jobs, but they are far better off then the wave that came in the late 90s.