Guest post from Jeff Sutherland, co-creator of Scrum and CEO of Scrum Inc.
In case you missed it, earlier this month VersionOne broke record attendance (5,000 registrants) for our AgileLIVE webinar series. Jeff Sutherland keynoted the event with a focus on “doing twice the work in half the time” with agile and Scrum principles.
Jeff must have said something right because the attendee questions flooded in. Since we ran out of time to answer all of them on the live webinar, we asked him to answer the most common questions right here for you to learn and share. If you find these helpful, please download the full recording of AgileLIVE: “Getting to Done – The Power of Scrum.”
Q: Do we need some initial design done before we engage a developer?
A: The designer should be part of the team. How much design needs to be done should to be worked out in the team before coding begins? This question is similar to, “Do we need a tester before we can ship?” All people necessary to get to Done need to be on the team working as a team.
Designers struggle with this concept when they are not cross-functional and tend to work across teams. At Scrum Inc. we put a design expert on one team even if they have to help other teams.
Q: How is Story definition effectively managed? Is Story definition considered part of a Sprint?
Getting user stories or product backlog items in a ready state takes place during the previous sprint in product backlog refinement. The Team and ScrumMaster should expect to spend about 10% of their time working with the Product Owner to refine the stories for the coming sprint during the current sprint. We have tried to make this clear in the Scrum Guide at scrumguides.org.
Q: We know that Scrum can be applied outside of coding software. What generic term would we replace “Working Software” with in the Agile Manifesto for efforts that are not software development efforts? Working Deliverables?
Joe Justice leads our agile hardware practice. He uses this wording:
“The Agile Manifesto applies to all industries. When we read it and its 12 principles, and switch each mention of “software” with “customer visible value,” we have an elegant methodology that applies to all business.”
Q: We are applying agile and Scrum methodologies to marketing efforts (with adjustments for marketing). Have you ever worked with or witnessed agile in other areas beyond software? Do you think it works?
One of the driving motivations behind publishing my new book, “Scrum: the Art of Doing Twice the Work in Half the Time” was to show how effective Scrum could be in all industries. In fact 80% of the examples in the book are non-software related.
My company Scrum Inc. is a business services organization and we Scrum everything: marketing, finance, sales, and content creation. Many of the companies I work with use Scrum in marketing. Sometimes the marketing Scrums are better than the development Scrum teams.
Q: What are some of the approaches you recommend for getting to consistent story points, especially across teams?
Getting consistent story points across teams is not important. What you want to look at is acceleration across teams. Teams will estimate in ways that makes sense to each individual team.
However, Scrum Inc.’s Chief Product Owner Alex Brown has conducted a number of experiments. He found that dropping similar backlog items into different teams’ backlogs can give a Product Owner a pretty good idea of point variability between teams. He then estimates how long it will take to complete an epic that is being worked on across multiple agile and scrum teams.
For non-agile organization’s looking to transform, LeSS and SAFe might be good places to start. However, these prescriptive scaling frameworks can eventually become a major impediment as the organization’s agility matures. LeSS is closer to Scrum principles. SAFe adds extra overhead.
We talk about the basic components of scaling in our Scrum@Scale online courses at scruminc.com. There we describe where SAFe and LeSS might be useful. We also point out that scaling agile needs to fit the organization and its goals. A company like Spotify would not use prescriptive frameworks. Large companies we work with that start with SAFe soon find they need to change the organization and eliminate waste, which moves them beyond SAFe. Dean Leffingwell points out that SAFe is a starting point.
Scrum is fractal and based on Object Oriented Architecture. It was designed to scale. In fact, the first scaled Scrum pre-dates the Agile Manifesto by many years. It was similar to the approach Spotify uses today.
Product info – Scaling agile and scrum with VersionOne
Webinar recording – AgileLIVE: “Getting to Done – The Power of Scrum”
Blog post – SAFe and Other Frameworks for Scaling Agile
Software testing takes time. Much of this time is often spent writing bug reports for failed tests. Integrating Axosoft with TestLodge can save you and your team time by improving this process. TestLodge Test Management is an online test case management tool that allows you to store and manage test plans, test cases, requirements, and more. QA teams love using TestLodge because it helps them stay organized and ensure their testing process is smooth and documented with ease.
Axosoft integrates easily with TestLodge, allowing you to automatically create bug reports in Axosoft whenever a test fails in TestLodge. This leads to a more streamlined testing and bug reporting process and eliminates the time testers spend creating bug reports manually.
Setting up the integration is simple. First, you need to allow TestLodge to access your Axosoft account. Once you’ve permitted TestLodge to access your Axosoft account, you’ll need to associate a TestLodge project with an Axosoft project.
Now when a test is marked as “failed” in TestLodge, a bug report will automatically be created in the Axosoft project, including relevant information such as steps to reproduce the bug, the expected result, and the actual result. You can select the Axosoft release, the priority, and assign a user to the bug directly from TestLodge. TestLodge will even set the reporter of the bug as the person who failed the test.
Learn more about setting up the integration in this short video:
As you can see, this integration provides instant communication of bugs and necessary information from your testers to your developers, which leads to a more efficient testing process. Once you’ve completed a round of testing and bugs have been fixed, you can then re-run all failed tests in TestLodge to verify the fixes.
By integrating these two products you’ll add value to your testing and development teams in a number of ways:
- Save time spent logging bugs manually.
- Streamline communication by instantly sending failed tests as ‘bugs’ to Axosoft.
- Synchronize your testing and development teams by ensuring both sides have the information necessary to resolve bugs and make quality software.
Full of new enthusiasm courtesy of his impromptu mentor Rex, Peter was eager to try some of them out in the next race. He went home and immediately proceeded to write down some ideas for “pulling” with instead of pushing the team, like Rex had advised.
After giving it a little thought, here are a couple of the things he came up with:
- I will let people know what I see happening so that everyone on the boat has the same information that I do and can act accordingly.
- I will ask for feedback. For example: As we complete a tack, ask the jib trimmer if he feels enough pressure on the sail. Adjust my driving to help compensate.
There, he thought, that seemed like a reasonable place to start.
So when the next race came around, Peter shared his ideas with the team (well, those that came back anyway). The team was cautiously receptive. That was good enough for Peter.
So once more they went back out onto the race course. This time it went better. They managed to get a start in the middle of the fleet, and they even managed to hang on to their position all the way to the windward mark. That’s when things got complicated.
Things got crowded at the mark and Peter’s boat lost a lot of ground. They managed to to claw back some ground against the competition on the final run, but they were still in the last half of the finishers – definitely not where Peter wanted to be. On the bright side, instead of fleeing the boat when they reached the dock, the team decided to join Peter for a beer back at the clubhouse.
After having a round with the team, Peter found Rex. “So how did it go?” Rex asked.
“A little better. We did great on the first beat and managed to keep up with the pack.” Said Peter.
“I saw you were in the game. Nice job!”
“Yeah, but we blew it at the first mark.” Said a rather dejected Peter.
“Well, we tried out some of the stuff that you recommended. I came up with a few ideas and shared them with the team. They seemed to work, but then things got stressful and I forgot to do the stuff I’d committed to doing. I couldn’t help it. There was just too much going on.”
Rex shook his head, “Actually I kind of expected that. It happens a lot to folks when they start pulling. Don’t sweat it, you’re off to a promising start.”
“What do you mean?”
“Well, it’s like this: you understood the idea I was trying to convey. That’s a good start, but what you need to do is to show everyone how it works. You need to set the example.”
“I still don’t get it.”
“Let’s take a concrete example: before the next race, here’s what I want you to do. Switch places with anyone on your crew. It could be the trimmers, the bowman, the pit. Anybody at all. Your job for that race? To dedicate every ounce of your passion to performing the best you can. Bring all the love you have for sailing to the role. Show everyone what that looks like.”
“But if I do that who will drive the boat?” asked Peter.
“It really doesn’t matter. It can be anybody – after all, steering isn’t that hard.”
“Wait a second, I spent a lot of money on a boat so that I could be the man at the tiller.” protested Peter.
Rex nodded his head, “Precisely, and until you learn to share that passion and that responsibility with everyone on the boat, you will never win a race.”
“What if I’m not that good at the role? Won’t people just think I suck?”
“No, in fact you will probably gain some credibility with the team if they see you failing – what matters is that you are working along side them pulling for the win.”
“I don’t know…I just want a good crew that will help me win races.” said Peter.
“A good crew is something that you build together. It has to be a joint enterprise that everyone has a stake in. I don’t know of any better technique to get there than by pulling.”
Peter put his head in his hands and groaned. This really was a lot more than he had bargained for. He just wanted to win a race! It was infuriating!
Peter looked back at Rex, “OK, man. I’ll give it some thought. I’ve really got to wrap my head around this.”
Rex winked at him and replied, “Take all the time you need.”
Filed under: Agile, Blogroll, leadership, pull, push
Why do I have conversations like this?
Last week, a got a question about electronic task boards. I could smell another one of these 'yes, but' discussion starting, so I chose to answer the question with a question: Why are you doing Scrum? I drew this picture on a flip chart and invited the participants to put dots on the location corresponding to their (organization's) goals:
Most dots were to the left of middle, the low performance choice, which explains why people did not like the high performance answer.
Scrum is based on the patterns of the 95th percentile of project performance, i.e. those awesome teams that are 3 to 10 times more effective than average. Those patterns are probably the same patterns as you experienced in your own best projects!
So why are you doing Scrum?
Angela Johnson, PMP, PMI-ACP, CST is a founding member of Collaborative Leadership Team, a Certified Scrum Trainer and Agile Transformation Coach who is passionate about changing the world of work. She seeks to help people and organizations to break down their barriers and work together in a collaborative way. Angela brings 20+ years in the information technology space and real world client case studies to her presentations. She is a mom, wife, sailor, reader and lifelong learner living in Minnesota.
As a recreational sailor and a woman, I do not think of myself as a Woman in Sailing. I think of myself as a sailor. The most common phrase uttered at the yacht club where I learned to sail was right from Woody Allen “80% of life is showing up”. If you want to sail, if you want to race, if you want to be put into the game “you have to show up”. This phrase was not used with the females interested in sailing, it was shared with anyone interested in sailing. So what is up with “Women in Agile?”
In my 20 years working in the male-dominated Information Technology field and the 11 years I have been involved in Agile and Scrum communities, I have never thought of myself as a “Woman in Agile”. I view myself as an Agilist. A Certified Scrum Trainer (CST). Not a Female CST. My belief has been you have to show up to play. If women want to be included, where are they?
And today, instead of asking “Where are the women in Agile and Scrum” I find myself asking “Why aren’t the Women in Agile and Scrum showing up”?
Perhaps I am asking this after reading what happened to Adria Richards at the Open Source Conference PyCon, also known as donglegate: http://tinyurl.com/ob8ez34
When women have shown up to Agile or Scrum conferences, user groups, online forums, etc. have they been treated the same way that their male counterparts have? Maybe some had experiences such as Adria Richards and rather than say something, they simply stopped showing up?
In May I looked around the Scrum Trainers and Coaches retreat I was in and only saw 1 other female. The remaining 50+ participants were men. As I participated in discussions, I was talked over, disregarded, turned away from and angrily responded to if my response differed from some of the participants.
Kudos to the male participants there who intervened and asked that everyone involved be respectful of one another and not to interrupt, talk louder over someone to drown them out, etc.
In an online forum of Scrum Trainers and Coaches that I subscribe to, my posts are repeatedly disregarded or in many cases hijacked and turned into something I did not intend. As a result I have ceased my involvement in that forum.
The Scrum Values we teach in Certified ScrumMaster training are Focus, Openness, Respect, Commitment and Courage.
My appeal to the Women in Agile or Scrum and to the Men in Agile or Scrum is to view us all as People in Agile and Scrum. We ideally are all trying to promote a different way of doing work that is value and principle based.
Let’s encourage each other to be Courageous. Let’s encourage each other to be Open. Let’s Focus on outcomes and not who or where the idea originated. Let’s be Respectful of each other. If we all Commit to living the very values that we teach, perhaps more women will feel like they can show up.
Partnerships & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: THE DIFFERENT FACES OF LEADERSHIP
[Introduction] FutureWorks is a virtual team.
[01:00] In HBR’s newest issue, “Getting Virtual Teams Right” by Keith Ferrazzi.
[03:00] You can model three tiers of team members – core, operational, and outer.
[05:45] Calculate your team’s virtual distance – factors that exacerbate the challenges for a given team.
[09:00] Operational distance as opposed to Physical distance.
[10:00] Affinity distance.
[13:00] How many managers stop to think: “How I recruit, assemble, and construct this team will have a big impact on the outcomes I will get from them”?
[16:30] The moment “us” and “them” begins to form on a team, trust and therefore performance, erodes.
[18:40] When management begins to consider putting together cross-functional teams, it is worthwhile to pass out copies of Ferrazi’s article to everyone, and ask – “Have we considered all these factors?”
Andy Hunt, the Pragmatic Bookshelf publisher, just sent me an email telling me that Manage Your Project Portfolio is featured in La República, Columbia’s “first and most important business newspaper.” That’s because getabstract liked it!
And, I have to say, I’m still pretty excited.
If your organization can’t decide which projects come first, second, third, whatever, or which features come first, second, third, whatever, you should get Manage Your Project Portfolio.
Bobtuse can be wildly informative
I usually smile when I hear a statement like this: “Our culture is way too …” fill in the blank “Agile just won’t work here!”
Why do I smile? I find that people are typically referring to a common belief that in order to be “agile” an organization’s culture needs to be one of “trust”. The belief is that an organization should trust its people to:
(1) make the right decisions, and
(2) do their best to deliver products and services that will make the business succeed.
All good stuff, very good in fact. But, good or not, its a really steep hill to climb for an organization’s culture to go from (a) low-trust: managing projects for performance against their time, cost and scope commitments while focusing on departmental efficiencies to (b) high-trust: self-managed delivery systems that act responsibly within the available time and budget.
As we see in HBR’s article on organizational culture “Culture is powerfully shaped by incentives”. As a result, we need to figure out how to (a) build trust, and (b) change the incentives. Doing this is actually fairly straight-forward if you are working with your business’ leadership and solving for their issues. What are their issues? In most organizations, their issues are how to make and meet commitments in a way that is within their defined budget.Finding Better Ways to Meet Needs
Becoming agile isn’t about using this method or that method. It’s not even about trust. Its about creating a system that can respond to change in a way that creates safety for the business’ leadership by respecting their immediate needs. So, instead of trying to just go out and be agile, I think we need to start with a business need and find ways to meet it while creating safety for the individuals involved. We need to create a roadmap to go from point a to b.
Most business leaders are desperate for better ways to deliver against their commitments while having the ability to adapt their plans along the way when things change. Most leaders are absolutely thrilled to trust their people; but, remember, to establish the trust we have to be willing to first make and meet commitments in a way that shows them we can be trusted.
We hope you enjoy this holiday poem on Sprint Planning. It was an early holiday gift to the Agile Management Blog from Daniel Gullo, owner/principal of Apple Brook Consulting. Thanks, Daniel!
‘Twas the night before Sprint Planning, and all through the Team
Not a member was worried about the upcoming theme.
The Stories were refined and the Backlog was set;
Poker had been played without a single bet.
Appropriately sized and estimates all sound;
Acceptance Criteria to establish firm ground.
The ScrumMaster and Product Owner had just finished a call,
To talk about ordering and a potential Sprint Goal.
The Retro had happened several days prior;
The Scrum Team had discussed how to move the bar higher.
Agreements were revised and the Definition of Done
Included more testing and other such fun.
The stakeholders were eager to see the new stuff:
“The product has value!! Perhaps we have enough??”
In the last Sprint Review, the Team had shone bright,
A shippable increment, a product in its own right.
Wouldn’t be long ‘til the Team would release,
Causing the customers’ delight to increase.
The CEO and the VPs were finally content,
The decision to be agile had caused no lament.
Developers are happy in practicing their trade
Testers are ecstatic they are no longer blamed.
And everyone has a chance to really collaborate
Without worrying about the build being late.
As dawn approached and meeting was nigh,
The Team members were up on an adrenaline high;
Excited to move forward and full of new hints,
The wonder of Scrum and working in Sprints.
“Is agile right for me?” you may be wondering,
As your organization continues with delivery blundering.
If your culture is ready to be focused on learning,
Agile will help you return to positive earning.
Get more info on sprint planning within VersionOne.
Software development on anything more than a pet projects is a collaborative activity. To enable a group of developers to make any headway, some details inevitably need to be hammered out together. However, you probably find that getting agreement within a group of opinionated developers can be difficult at the best of times. Most software developers haven't had training in "soft skills" and you may find it hard to know where to start when a difficult question needs to be thrashed out.
Here are some pointers to areas that you might want to explore beyond the realm of programming languages, methods and frameworks.
Facilitation is all about making conversations easier but even with a clear meeting purpose and agenda, you may find meetings can go around in circles without reaching consensus. To understand some approaches to making group decisions I recommend "Facilitator's Guide to Participatory Decision-Making" which introduces decision making rules. You can also get affordable hands-on training in facilitation from non-profit ICA-UK on Group Facilitation Methods.
Another thing you can do to help meeting participants is to create visible agendas and capture points being discussed concisely. If you want to build more confidence with writing neatly on flipcharts and whiteboards, seek out a course in graphic facilitation where you can pick up tips and practice with other budding facilitators. To improve how you illustrate system dynamics in group discussions, start to practice drawing Diagrams of Effects. Peter Senge's book "The Fifth Discipline" has a an excellent introduction to Systems Thinking and an handy set of system archetypes that you can use in different situations.
There's an old joke: What is the difference between a Methodologist and a Terrorist? You can negotiate with a terrorist! When discussions get heated, it's handy to know a little bit about negotiation techniques. The Harvard Negotiation Project have put out a few paperbacks and I recommend "Getting Past No: Negotiating With Difficult People" by Fisher and Ury. Another easy read around building trust is "The Trusted Advisor" by Maister, Green and Galford.
Lastly remember that we can improve communication in our teams by starting with ourselves and how we express our own opinions. A good place to start is "Nonviolent Communication" by Marshall Rosenberg. An older book that's worth getting hold of to get a different perspective on the way you share feedback is "The Art of Giving Feedback" by Charles Seashore and Gerald Weinberg.
I hope these resources help you in situations where you need to go outside your comfort zone. Please do let me know if you have other recommended reading to share that goes beyond coding.
So needing to have this conversation today, I had the time to do a search for some help. And I found this wonderful article and video with a voice over explanation.
Business Benefits of Software Release in Multiple Increments
And there is an interactive Wolfram graphic you can play with yourself.
Now with this link and the video explanation (done with a german accent I think, gives it real authority) - I can solve the problem of coming to that shared understanding.
Have you been in a meeting lately where people were focused on their laptops, interrupting each other, distracted, or otherwise behaving badly? In Jean Tabaka’s “Leading Collaborative Meetings” class, Jean talks about the importance of working agreements to create the safety that makes productive dialogue possible.
When I see people facilitating meetings around here, there are some common working agreements that show up often:
- “One conversation at a time” helps people hear each other.
- “Electronics by exception” enables people to stay focused on the work rather than getting lost in their devices.
- “Start and end on time” is important if your discussions tend to run long.
But we also do a lot of large-scale meetings with 50, 100, or even 500 people working collaboratively on a plan. And at scale, some of these agreements don’t work as well. “One Conversation at a time” doesn’t make sense much of the time. With 500 people, some are going to come and go.
So here are some of the agreements we’ve experimented with when more than 100 people are trying to agree on a plan, along with how we explain the working agreement to the group.Aim for Good Enough
“With 300 people here, we’re trying to get to a reasonable degree of alignment. We’ll continue working on our plans throughout the release. When you’re engaging with the larger group, think about whether your issue needs to be discussed with everyone or whether it can be resolved with a smaller group. If we’re getting stuck, think about how a small group can work to bring back a recommendation to the larger group.”Be Back on Time
“Large group meetings are expensive. It’s really important to be here on time so we don’t have hundreds of people waiting for you. This matters a lot when we come back together at 4 pm today, and when we start tomorrow morning.”Raise Risks Early
“If you know of an important risk, raise it as early as you can. During the morning activity is your first chance; then during your breakouts you can also raise issues early. If you can resolve the issue today, that’s way better than making us stay late tomorrow.”Leave if You Need to Do Other Work
“We have so many people here, there’s a good chance something will come up that requires some of us to shift our focus. If you do need to do other work, please step out completely so that the rest of the group can focus.”
We’ve had some success with these, especially when the “regular” working agreements have already become the cultural norm. What working agreements do you use in large-scale planning meetings?
Learn how to lead productive, enjoyable, effective meetings. Sign up for Jean Tabaka’s “Leading Collaborative Meetings” class today.Alex Pukinskis
I once worked in an organization where the senior managers thought they should motivate us, the team members. They decided to have a team competition, complete with prizes.
I was working on a difficult software problem with a colleague on another team. We both needed to jointly design our pieces of the product to make the entire product work.
After management announced the competition, he didn’t want to work with me. Why? There was prize money, worth hundreds of dollars to each person. He had a mortgage and three kids. That money made a big difference to him. I was still single. I would have stuck that money into either my savings or retirement fund, after buying something nice for myself.
Management motivated us, alright. But not to collaborate. They motivated us to stop working together. They motivated us to compete.
Our progress stopped.
My boss wanted to know what happened. I explained. I couldn’t fault my colleague. He wanted the money. It made a big difference for him. I would have appreciated the money, but not nearly as much as he would have. (Later, when I was paying for childcare, I understood how much of a difference that money made.)
I then had this conversation with my boss, ranting and raving the entire time:
“Look, do you want the best product or the best competition?”
“You can’t have both. You can have a great product or you can have a great competition. Choose. Because once you put money on the table, where only one team gets the money, we won’t collaborate anymore.”
My boss got that “aha” look on his face. “Hold that thought,” he said.
The next day, management changed the competition. Now, it was about the teams who worked together to create the best product, not the one team who had the best idea. Still not so good, because all the teams on the program needed to collaborate. But better.
When I had my one-on-one with my boss, I explained that all the teams needed to collaborate. Were they really going to pay everyone a bonus?
My boss paled. They had not thought this through. “I’d better make sure we have the funds, right?”
People don’t work just for money. You need to pay people a reasonable salary. Remember what Dan Pink says in Drive: The Surprising Truth About What Motivates Us. People work for autonomy, mastery, and purpose. If you exchange the social contract of working for autonomy, mastery, and purpose for money, you’d better pay enough money. You also better repeat that money the next time. And, the next time. And, the next time.
That’s the topic of this month’s management myth: Management Myth 35: Friendly Competition Is Constructive.
Software product development is a team activity, full of learning. As soon as you make it a competition, you lose on the teamwork. You lose the learning. Nobody wins. There is no such thing as “friendly” competition.
Instead, if you go for collaboration, you can win.
You know that great feeling you get when you meet someone and instantly hit it off? You realize that you know people in common, feel like you could have endless conversations, and get excited about the same things. Over the past few months, that type of connection sparked the partnership we announced today between Rally and Code for America, the organization championing the civic-tech movement. Because of our shared mission and values, we’re combining our talents with technology to better communities nationwide.Bring on the Brigades
Furthering our missions. At Rally, we believe empowered people who can adapt to change and harness their collective creativity are essential for solving today’s big problems. We’re excited to further this mission and equip teams to innovate and thrive by sponsoring the Brigade program, a citizen-driven network of 4,500 volunteers. Working in partnership with municipal governments, nonprofits, and other civic groups, Brigade members use technology to address local problems or create new opportunities.
You can contribute your skills to the cause by joining a team, writing code, or even launching your own Brigade:
- Find a Brigade near you.
- Start coding today: the Civic Tech Issue Finder shows help wanted for open GitHub issues.
- Mark your calendar for the annual CodeAcross event, Feb 20-22 (in January, the website will show sites hosting an event).
- Really want to jump in? Watch the How To Start A Brigade video.
Sharing our talents and tools. In a world driven by software, Rally is convinced that Agile helps accelerate the pace of innovation to help people create products that users love. As a leader in building Agile teams, Rally is giving the Brigades open access to its renowned software tools to help improve team communications, coordination, and project management. We’re also helping the Brigades tap into the talent and expertise of our people to fully realize the benefits of being an Agile team — because working together faster, more efficiently, and more collaboratively to achieve better results will foster civic innovation that benefits everyone.
By working closely with the Brigades, Rally employees get to hone their skills in a different environment — a safe sandbox in which to explore, experiment, and practice. As a company, we’ll learn more about how disparate teams work and how we can use our tools and people to add value to the team experience.
Investing in the Civic Tech Movement
Program funding. A year ago, we created the Rally For Impact Foundation with a 1% equity donation from our 2013 IPO. As part of our investment in Code for America, we are donating $50,000 (our largest grant award to date) to help fuel the growth and development of the Brigade network. When we set aside 1% of equity several years ago, we laid the groundwork for realizing our vision — extending our impact beyond our employees and customers to be a part of a global, growing movement of cooperative collaboration between citizens and their communities.
Goals for year one. In 2015, we’ll partner closely with a handful of Brigades. Rally employees will mentor each of these Brigades to help them apply Lean and Agile techniques to project creation, planning, and execution. Plus, in U.S. locations with Rally offices (namely Boulder and Denver Colo., and Raleigh, N.C.), we will create meaningful opportunities for employees to get directly involved — such as joining and mentoring Brigades, working on open GitHub issues, participating in the CodeAcross event, and hosting hackathons. In addition to software developers, the Brigade movement needs people with the skills necessary for a successful technology implementation, including project managers, designers, data analysts, marketers, community organizers, and subject matter experts.
Learning what Brigades need. During the first year of our partnership, we’ll explore ways in which Rally can best contribute to the Brigade movement from a product and people perspective. We know from experience working with hundreds of customers that technology development projects leveraging Lean and Agile practices help teams collaborate better and are more successful in bringing the right solution to the people who need it. We’re ready to mentor and train Brigade leaders and members in these practices, but first we need to understand how to apply them to grassroots, volunteer-driven teams in a way that can scale to eventually reach the entire Brigade network.
Agile toolkit for Brigades and beyond. In collaboration with the partner Brigades, we plan to use what we learn in 2015 to create an open-source toolkit for civic technology projects. The toolkit will be designed to help anyone learn and apply Lean and Agile techniques, methods, tips, templates, worksheets, and tools that will benefit them in their project work.Learn More
Code for America
- Code for America (website)
- Code for America: Building 21st Century Government (video)
- Coding a Better Government (TED Talk by Jennifer Pahlka, Founder and Executive Director)
- Where We’ve Been, Where We’re Going (Jennifer Pahlka’s Blog November 26, 2014)
- Brigade Program (website)
- Learn about the Code for America Brigade Program (video)
- Why Good Hackers Make Good Citizens (TED Talk by Catherine Bracy, Director of Community Organizing)
- Brigade project examples: Balance, CyclePhilly, Soft Story, Open Disclosure Oakland, Flu Shot Finder, US Cities Open Data Census
“Only one room
Only one way
Key is alive
Leave or stay"
Spoiler Alert --- some puzzles are solved below.
Collected Items ————paper scraplamp shadescrewdrivertesla bookUSB cord
Book Shelf - opens Screwdriver-------------------------------------Aristotle 384 BCERoger Bacon 1214 - 1292Leonardo Da Vinci 1452 - 1519Copernicus 1473 - 1543Galileo 1564 - 1642Newton 1642 - 1727Faraday 1791 - 1867Tesla 1856- 1943Alan Turing 1912 - 1954Stephen Hawking 1942
3 Stars - 5 points; ball on one point - 1 missing star; color of stars & books may signify the overlap of authors livesshark - pinguen - robot - got a USB cord in drawer(^^^) <(“) :|]
Bird - Dog - Elephant - Dolphin (brown yellow gray blue)A-Z 4-charblue red green 3 colors0-9 7 numbers4 greek letters - Theta, Sigma, Psi, OmegaTh, S, Ps, O9, 200, 700, 800
Picture of sheep man dog house trees clouds
by Egidio Graziani6 places (sheep, man, dog, house, tree, cloud)alphabetical order (cloud, dog, house, man, sheep, tree)order in picture left to right, eye flowing, front to back
buttons rotate in this order: cloud, sheep, dog, tree, man, house....
Table with Globe - gave a board with numbers (1-6)golf ball micro phone oscar statue W7 letters A-Zphonic alphabet Golf, Mic, Oscar GMOW GMO over Whiskey
Globe - six symbols
mirror over 4 drawer chestdrawer 1 top 8 point double ring w 4 push buttonsdrawer 2 3 blocks, 7 bundle, CBA, dart board 4 digitsdrawer 3 4 x 4 buttonsdrawer 4 4 x 4 buttons labeled ABCD 1,2,3,4 (Nice Room)
left side of bed clock with one hand000 000 00dial lock
above bed - picture of man and sheep (moves left right up down) center above bed
right of bedbox 9 box form letters two buttons
5 x 7 white gray black buttons on boxempty shelfbox with cyan red yellow triangle
dart board score = 172triple 18 double 15triple 16double 14twelve
8 segment clock with 3 hands 3:5:7 = 3/8 : 5/8 : 7/8big hand on 3med hand on 5small hand on 7
Largely learned nothing... except there is a really good cheat site: AppUnwrapper
Yeah, OK, I used a few of the cheats - but that's not a lot of fun...
Oh - and many of the puzzles have additional clues or items to pick up once opened. These items/clues are not visible until the lock is opened. For example a clue written on the back of the door.
I have two games running. So I took the opportunity to run a few experiments.
I had the Globe open in game A. In the second game, B, I keyed in the sequence of buttons for the Globe but it didn't open. Then I went over to the picture on the sheep, man and dog and applied the number overlay - POP! the Globe opened. What does this tell us? That locks are turned off by default and actions must turn the locks on. Such as the Globe, which was turned on by the number overlay being applied to the painting.
So... off to solve a 4 equation; 4 variable problem.
The bottom drawer (right of bed):
1) 48 x + 88 y + 2 z + 7 a = 86
2) 55 x + 4 y + 71 z + 86 a = 23
3) 6 x + 87 y + 28 z + 88 a = 4
4) 3 x + 26 y + 81 z + 74 a = ?
OPPS that didn't work out
CBA code is solved by hint
2a + c = 113
a + 2b = 93
b + 2c = 61
a = 47; b = 23; c = 19 --> 192347 = CBA