- Nat Pryce - Weds 1st April - FREE, EVENING EVENThttp://edinburgh.bcs.org/events/2015/150401.htm
- Kevlin Henney - Agile Architecture course Thursday 4th June - DAY COURSEhttp://edinburgh.bcs.org/courses/150604_architecture.htm
I have become really excited about the potential of bringing an excited, passionate group of experts into room to work on challenges and problems that inspire them! So I am really excited about the Product Owner Camp in Switzerland!
Product Owner Camp in Switzerland (#POcampCH) is an Open Space conference inspired by the successful Agile Coach Camp in Kandersteg and Scrum Coaching Retreat in London. Unlike its role models, #POcampCH focuses on product creation: "Product Management meets Product Ownership: How do we create great products together?"
Thursday kicks off with an optional master class, "How to Get Quickly from Idea to Minimal Viable Product?" led by Karen Greaves, Samantha Laing, and Steve Holyer. Social activities are planned Thursday and Friday evening for attendees to interact, learn, and get to know each other.
Friday and Saturday, all day, involve all participants to conduct a series of parallel sessions addressing current topics around product creation and development in a Scrum/Agile/XP/Lean/Kanban context. As an Open Space "Unconference" event, the participants define the program. This is an exceptional opportunity for Agile leaders to collaborate and learn from each other. Saturday afternoon is a wrap-up of the POcampCH that involves attendees retrospecting on the event and looking toward the future.Target audienceThe Product Owner Camp in Switzerland is for practitioners involved in product creation, from the idea to the realization. Product Managers, Product Owners, Designers, Developers, ScrumMasters, Agile Coaches, Testers, Entrepreneurs, Innovators and Managers. Not on the list? No worries! If you create new products, POcampCH is for you!
As a Scrum Alliance sponsored event, you can earn Category A SEUs toward your Certified Scrum Professional.
Prices start at CHF 299 / person in double occupancy (yes, this includes your hotel costs!) or CHF 368 for single occupancy.
Dates: June 11 (18:00) to June 13, 2015 (17:00). Optional all-day Master Class on June 11. For more information, registration, and to find out who else is coming, see http://pocampch.org/!
To all Pulse customers, existing and potential, a bit of news: we’ve applied some long-overdue changes to pricing. Well, not changes so much as clarification! Since the initial release of Pulse we’ve always favoured an up-front pricing policy. We loathe hidden pricing designed to lure you into a lengthy, pushy sales process. So our sales front page has always included pricing information.
However, the pricing on the page didn’t show the full reality. We had three tiers of pricing for 1, 5 and 15 agents, then the option of license 10 packs on top. In practice customers often asked a few questions:
- Can we get a more specific number of agents, e.g. 10?
- Can Pulse handle large numbers of agents, well beyond 15?
- Do discounts apply as the number of agents continues to grow?
In all cases the answer has been yes. We aim for flexibility, and have allowed anyone that asked to purchase a smaller number of agents at a time. Pulse can certainly handle many more than 15 agents: some customers have hundreds in production and we’ve always offered discounts for high numbers.
Thus it is about time we reflected reality in our published prices. From now on there are no defined agent pack sizes: you start with a single agent license for US$900, then add as many additional agents as you need. Agents are priced on a sliding scale so they become progressively cheaper as your installation grows. You can see this clearly on our updated sales page.
What does this mean for existing customers? As a matter of policy: no existing customer will lose out. If you have a deal better than the new published pricing, that deal remains. This may mean you can get more agents free, or a discounted renewal price next time around. For reference: the original single agent license is now US$50 cheaper, and this will translate to a US$25 discount for our existing Pulse Standard License holders. The pricing for 5, 15 and 25 agents remains identical, so many customers will see no change. Larger licenses will be dealt with individually as they come up for renewal.
We think this new pricing better reflects our aim to be both up front and flexible. If you have any questions, please contact sales.
Another short video for your viewing pleasure! Kanban in One Minute – Do It Right by Michael Badali.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Organizational change will always be an endless journey and this journey will always be personal and unique. This post from a couple years ago mapped out a possible path people may navigate through an Agile change journey and just how unique this experience can be.
Many organizations expect a “point a” to “point b” route when introducing change into their system. Introduce a specific change framework or select the latest “methodology of the day,” hire a fleet of coaches and consultants and in no time at all we will arrive safely at our destination of cultural and productive bliss.
But things get messy. A plan rarely survives real-life. The straight line never stays very straight. This environment of change, uncertainty, and ambiguity is often unsettling to many (including myself at times).
So, how can you prepare people for this winding road of change? Can we prepare them at all? While you will never be able to calm every nerve or address every concern, can we help people become more comfortable with the discomfort of change?
As a participant, leader, and coach, I have been involved in introducing change to many large companies and when I sense I am around someone who is nervous or anxious about the road ahead, I have a couple of topics I bring up in my conversations with them.
Shifting to an active voice as if I would be talking directly to someone, here are some of the things I bring up:
Enter with eyes wide open. Understand and accept this will not be easy and there may be days that don’t go very well. Days when nothing seems to be working and you would like to rip every task card off the wall. Days when you just don’t get it and want to fall back on existing habits and processes. This is all normal and a good sign you are human like the rest of us. While this will be exciting, I can guarantee there will be periods of confusion, questioning, fun, camaraderie, extreme productivity, and stalled efforts…perhaps all in the same day.
Soak it all in. Pull from a variety of sources and learn about well-functioning organizations and collaborative methodologies. Learn about Lean Thinking, Kanban, Scrum, and The Lean Startup. Discover elements of the change being introduced and study those as well. Begin to understand the roles and processes we are introducing and more importantly, why we are doing them. Learn about companies doing some of the things we are trying to implement. For example, find out how Facebook does automated testing and how 37signals delivers products as fast as they do.
Experiment. Treat everyday as a set of experiments. Take what you have learned, studied, and experienced in the past, mix things together, and create new experiences. Change is what you make it. What I have learned is I have enjoyed change the most when I made it an adventure.
Start to wander. Venture into other teams and other areas of the organization introducing their own change and see what is working for them or hear what they are struggling with. Often change is started in small waves of pilots. Not sure how the pilots are progressing? Talk to someone actively engaged on one and hear their story. Show up at a daily stand-up meeting and see how team interaction will be working in the future. Curious about the new Scrum Master role? Meet with one them over coffee and see how it’s done.
Going backwards. Or sideways. Or diagonal. Embrace the fact that this journey is uniquely yours. Just because someone else seems to have “gotten it” and you haven’t is ok. Frustration is natural but keep moving and stay engaged. The enemy to any movement is a lack of energy or an increase in apathy.
Please note, this post does not suggest an approach for calming the nerves during an organizational re-structuring when people are let go or removed from their job. It is not easy (or possible?) to prepare people for this type of change.Becoming a Catalyst - Scrum Master Edition
Well, it’s been some time in the oven (61 Big Picture revs so far), so we’re very glad to be delivering this news: The public preview site for SAFe for Lean Systems Engineering (“SAFe LSE”) is now open for public comment.
If you’re new to this subject, SAFe LSE is a freely revealed, publicly-facing framework with a comprehensive set of values, principles, and practice guidance that systems builders can use to help build large-scale, complex, software intensive systems (often called cyber-physical systems) in a Lean-Agile manner.
The business model is based on the successful experiences of applying the Scaled Agile Framework to complex systems development. (If you are curious about how well that is working out, check out the Case Studies. There is no substitute for objective results).
Designed to meet the growing needs of those building the world’s most complex systems that contain mechanical, electrical, fluidics, optics and other elements that are increasingly software intensive, the SAFe LSE framework draws from four primary knowledge pools: classical systems engineering, Lean thinking, Agile and scaled Agile (SAFe) development, and Lean Product Development.
The LSE “Big Picture” (http://www.safe-lse.com) provides interactive access to detailed guidance for the people that do the work, their major activities, and the work products that capture decisions and help guide the flow of work. SAFe LSE also features a Program Portfolio interface to SAFe, which facilitates visibility, alignment, and Portfolio level governance for software solutions developed under SAFe, as well those systems developed under SAFe LSE.
SAFe LSE is the result of collaboration between Scaled Agile’s Chief Methodologist, Dean Leffingwell, systems expert, Harry Koehnemann of 321 Gang, Scaled Agile’s Alex Yakyma and Inbar Oren, and a growing contingent of systems engineers in the field.
The preview site is a work in process. Most articles contain detailed guidance; some articles are currently in abstract-only form. All articles are open for comment. This public input will be used for ongoing development and refinement of the new framework, resulting in version 1.0 later in 2015.
Scaled Agile will be training and certifying qualified consultants and practitioners who will implement the framework in their enterprise or consulting environment. The first training course—Applied Lean Systems Engineering with SAFe LSE—will be held April 14–16 in Boulder, CO, and is sold-out. Additional courses are scheduled later in the year. Register at http://www.scaledagileacademy.com/events/.
We hope that this new framework provides value to the industry, and we welcome your input as SAFe LSE evolves to version 1.0 and beyond.
The SAFe LSE Contriburors: Dean Leffingwell, Harry Koehnemann, Alex Yakyma, and Inbar Oren
In its global survey of project management practices, PricewaterhouseCoopers (pwc) reported that 34% of project managers use agile methods at their companies, and a majority of PMs (62%) are certified Agile practitioners. Now, new research from advisory firm Software Advice gives you three more reasons to shore up your agile skills.
First: 48 percent of project managers are using agile software for non-software-related projects. Sure, Agile methodologies started out in the software realm, and 52 percent of projects are still development-related. But the surprising breadth and diversity of agile’s penetration into other business units reflects a growing recognition of agile’s efficacy.
Software Advice: Agile Project Management UserView, 2015.
Second: 49 percent of project managers cite training others as the most common challenge. Though project management software is often the scapegoat for training challenges, those of you who’ve implemented agile at your organization know that the toughest uphill battle isn’t always the software, but encouraging people to change their mindset and behaviors.
“Teaching people how to use the tool, at the end of the day, is not that hard,” says Lean UX advocate Jeff Gothelf. “[But] getting people to buy into the process and philosophy is two or three orders of magnitude more difficult than teaching someone how to use a program.”
This brings us to the third reason you should become a certified agile project manager: it signals to the world that you’re a serious learner and practitioner of agile. The growing ubiquity of agile practices and the need to help facilitate agile practices among colleagues requires professionals who’ve invested time and effort in the latest methodologies and mastered them. Get certified, and you’ll stand out as a professional in your field.
Join us for our next Agile Certified Practitioner (PMI-ACP) Exam Prep course, hosted by Rally’s Agile University. This three-day course qualifies for 21 Agile PDUs and will prepare you to ace the PMI-ACP exam. However, it’s also a great course for anyone seeking to obtain a thorough theoretical and practical understanding of agile. Here’s a look at some of the topics covered:
- Agile Manifesto and Frameworks
- Planning, Estimating, and Adjustment Practices
- Lean Basics
- Kanban Design and Value Stream Mapping
- Visible Communication and Information Radiators
- Iterative Risk Management
- Facilitation Techniques and Conflict Resolution
- Testing Tips and Techniques
If you’re considering obtaining or renewing your agile PM certification, sign up. Now is the time to hone those professional agile PM skills!Rally
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
In a previous post, I asked the question of how can we tell if we are succeeding with an enterprise agile transformation. In the post I’ll close with the notion of using a balanced scorecard for signaling progress towards the transformation’s core business drivers.
A couple of comments were shared after the last post was published that cautioned on the dangers of creating a scorecard that would not drive the “right” behaviors or that was too broad and couldn’t be connected with the transformation’s overall success. This was great feedback and I appreciate the engagement with the post.
In keeping with my desire to resolve this question, I’ll explore a bit more of the notion behind why many organizations are seeking a transformation. I think answering this question will help to frame up a sample balanced scorecard in another post. Thanks for continuing to share your thoughts and feedback along the way.So the question asks…
Why transform? I think it is fair to say that the number of reasons why an organization would seek an enterprise agile transformation could be as varied as the people of the world. Both unique and diverse. That said, I most often hear about the following handful of reasons for an enterprise to transform: (1) new competitive forces in the marketplace, (2) an inability to pivot or focus, and/or (3) quality issues. Frequently the statement goes something like this:
“Our competitors are startups and they will try anything to eat our lunch. It takes us almost a year to release a new idea into the marketplace and by that time we are several months behind the next startup.”
In this case I would probably orient around both (1) time to market and (2) innovation as key business drivers; but, it would be important to remember that innovation and time to market are usually not enough. We would need to keep our eye on the ball with regards to business, cash or (3) return on investment. So, using traditional balanced scorecard perspectives, I would orient Financial around ROI, Customer around Quality, Ops and Processes around Time to Market, and Innovation around continuous improvement.
What are your thoughts, would you identify different themes for the scorecard or change the placement of the themes into different perspectives? Looking forward to hearing the opinions and views to this approach.
Thanks for reading!
We all attend conferences for the great learning opportunity, and I’m sure many of us are filled with ideas that over time become distant memories and then fade away completely. Here are some of tips on how to maximise your conference learnings.
Schedule time in your calendar for the day after the conference to reflect. We schedule about half the conference time, up to a maximum of 1 day. Use this time to read through your notes, make action plans of how to use and apply your learnings.
Create a backlog with all the ideas you want to implement or try, whilst it is fresh in your mind! Remember to prioritise these and put in enough information that it will jog your memory a month down the line.
Share your notes with your peers – perhaps as a blog post or as sketch notes. These are two sketches Sam made during the gathering.
For every session or talk you attend, write down 1 action that you want to implement. This way, when you look back at your notes this one action will stand out and remind you.
Schedule a 1 hour report back session with your peers at work. Tell them about the sessions you attended and what you learned. Most importantly tell them about what you would like to try.
Create a short 5-8 minute podcast of yourself telling the story of what you attended and learned at the conference. This way you can listen to the podcast to remember what you learned and what was exciting. As a bonus your work colleagues can also listen to this
I’ve been playing around with Twitter’s API (via the tweepy library) and due to the rate limiting it imposes I wanted to stream results to a CSV file rather than waiting until my whole program had finished.
I wrote the following program to simulate what I was trying to do:
import csv import time with open("rows.csv", "a") as file: writer = csv.writer(file, delimiter = ",") end = time.time() + 10 while True: if time.time() > end: break else: writer.writerow(["mark", "123"]) time.sleep(1)
The program will run for 10 seconds and append one line to ‘rows.csv’ once a second. Although I have used the ‘a’ flag in my call to ‘open’ if I poll that file before the 10 seconds is up it’s empty:
$ date && wc -l rows.csv Mon 9 Mar 2015 22:54:27 GMT 0 rows.csv $ date && wc -l rows.csv Mon 9 Mar 2015 22:54:31 GMT 0 rows.csv $ date && wc -l rows.csv Mon 9 Mar 2015 22:54:34 GMT 0 rows.csv $ date && wc -l rows.csv Mon 9 Mar 2015 22:54:43 GMT 10 rows.csv
I thought the flushing of the file was completely controlled by the with block but lucky for me there’s actually a flush() function which allows me to force writes to the file whenever I want.
Here’s the new and improved sample program:
import csv import time with open("rows.csv", "a") as file: writer = csv.writer(file, delimiter = ",") end = time.time() + 10 while True: if time.time() > end: break else: writer.writerow(["mark", "123"]) time.sleep(1) file.flush()
And if we poll the file while the program’s running:
$ date && wc -l rows.csv Mon 9 Mar 2015 22:57:36 GMT 14 rows.csv $ date && wc -l rows.csv Mon 9 Mar 2015 22:57:37 GMT 15 rows.csv $ date && wc -l rows.csv Mon 9 Mar 2015 22:57:40 GMT 18 rows.csv $ date && wc -l rows.csv Mon 9 Mar 2015 22:57:45 GMT 20 rows.csv
Much easier than I expected – I ♥ python!
A workspace is a group of projects that you view all together on one page. Everything that you can do in an individual project—and then some—can be done in a workspace. You can estimate stories, plan iterations, attach documents, and accept or reject to your heart’s content. In addition to the basic stuff, workspaces give you some extra oomph to get through your day. On the Tracker team, we’ve been using workspaces for a while and now cannot imagine life without them. Here are a few ways we use workspaces every day.
My Work—all of it
Every workspace has a My Work panel that lists all of the stories you own in each of the projects in your workspace. You can choose to group stories by project or by state. As a tester, I like to see all delivered stories regardless of project, so I set my view to “By State.” Whenever I leave my workspace and come back, my choices stick, so I don’t have to choose again.
Compare burndowns side by side
Try this: go to your workspace and close all of your panels. Then select the Charts panel for each of your projects in the workspace. You’ll see charts for each project side by side that allow you to compare progress. A stalled project situated next to a high-velocity project will start quite a few conversations that will help get your priorities in order.
Search multiple backlogs at once
The Tracker projects are organized by platform, so we often have cross-project dependencies. Front-end stories are often dependent on some back-end plumbing. Likewise, a back-end bug fix may rely on a DevOps infrastructure chore. In a workspace, I can search for labels or story ids and see the current state and owner of related stories without leaving the workspace. I also like to keep up with all delivered stories in a workspace, so I can sign up and start providing feedback as soon as possible. Here’s the simple search string I use that keeps me focused on the next most important task:
Move stories between projects
In a workspace, it’s easy to move stories between projects just by dragging and dropping between panels. You can also select multiple stories from multiple projects and drag all of them to a different project (if the point scales are compatible, of course!).
Slice and dice projects for different flavors
Organize projects in different ways: by product, by platform, or by channel. For example, if you have separate projects for iOS and Android development, put them together in a “Mobile” workspace. Does your DevOps team have chores spread across multiple projects? Put them in a “DevOps” workspace. A project can live in more than one workspace, so you can group projects in different ways to see how they impact each other. Is your design team outpacing the dev team? Put them in a workspace to see how done design work stacks up against the dev backlog, so you can adjust priorities to get design prototypes to customers before the concepts go stale.
Ready to spice up your workspaces?
Check out our FAQ for step-by-step instructions on creating workspaces, and cruise through these blog posts for additional tips:
For more on the Chaotic domain and subdomains, read Dave Snowden’s blog post, “…to give birth to a dancing star.” The relationship between separating people that I talk about here, and the Chaotic domain, can be seen in Cynthia Kurtz’s work with Cynefin’s pyramids, as seen here.
On one of my remote training courses over WebX, I asked the participants to do an exercise. “Think of one way that people come to consensus,” I requested, “and put it in the chat box.”
Here’s what I got back…
1st person: Voting
2nd person: Polling
3rd person: Yeah, I’ll go with polling too
And then I had to explain to them why I was giggling so much.
This is, of course, a perfect demonstration one of the ways in which people come to consensus: by following whoever came first. We might follow the dominant voice in the room, or the person who’s our boss, or the one who brought the cookies for the meeting, or the one that’s most popular, or the one who gets bored or busy least quickly.
We might even follow the person with the most expertise.
MACE: We’ll have a vote.
SEARLE: No. No, we won’t. We’re not a democracy. We’re a collection of astronauts and scientists. So we’re going to make the most informed decision available to us.
MACE: Made my you, by any chance?
MACE: Made by the person qualified to understand the complexities of payload delivery: our physicist.
CAPA (Physicist): …shit.
If you’re doing something as unsafe to fail as nuclear payload delivery, getting the expert to make a decision might be wise. (Sunshine is a great film, by the way, if you’re into SF with a touch of horror.)
If you’re doing something that’s complex, however, which means that it requires experiment, the expertise available is limited. Experiments, also called Safe-To-Fail Probes, are the way forward when we want our practices and our outcomes to emerge. This is also a fantastic trick for getting out of stultefying complicatedness or simplicity, and generating some innovation.
But… if you stick everyone in a room and ask them to come up with an experiment, you’ll get an experiment.
It just might not be the best one.More ideas mean better ideas
In a population where we know nothing about the worth of different ideas, the chance of any given idea being above average is 50%. If we call those “good ideas”, then we’ve got a 50% chance of something being good.
Maybe… just maybe… the idea that the dominant person, or the first person, or the expert, or the person with the most time comes up with will be better than average. Maybe.
But if you have three ideas, completely independently generated, what’s the chance of at least one of them being above average?
Going back to my A-level Maths… it’s 1 – (chance of all ideas being below average) which is 1 – (1/2 x 1/2 x 1/2) which is 87.5%.
That’s a vast improvement. Now imagine that everyone has a chance to generate those ideas.If you want better ideas, stop people gaining consensus too early.
For this to work, the experiments that people come up with have to be independent. That means we have to separate people.
Now, obviously, if you have a hundred and twenty people and want to get experiments from them, you might not have time to go through a hundred and twenty separate ideas. We still want diversity in our ideas, though (and this is why it’s important to have diversity for innovation; because it gives you different ideas).
So we split people into homogenous groups.
This is the complete opposite of Scrum’s cross-functional teams. We want diversity between the groups, not amongst them. This is a bit like Ronald S. Burt’s “Structural Holes” (Jabe Bloom’s LKUK13 talk on this was excellent); innovation comes from the disconnect; from deliberately keeping people silo’d. We put all the devs together; the managers together; the senior staff together; the group visiting from Hungary together; the dominant speakers together… whatever will give you the most diversity in your ideas.
Once people have come up with their experiments, you can bring them back together to work out which one are going to go ahead. Running several concurrently is good too!
If you’ve ever used post-its in a retrospective, or other forms of silent work to help ensure that everyone’s thoughts are captured, you’re already familiar with this. Silent work is an example of the shallow dive into chaos!Check that your experiments are safe-to-fail
Dave Snowden and Cognitive Edge reckon you need five things for a good experiment:
- A way to tell it’s succeeding
- A way to tell it’s failing
- A way to amplify it
- A way to dampen it
- Coherence (a reason to think it might produce good results).
If you can think of a reason why your experiment might fail, look to see if that failure is safe; either because it’s cheap in time or effort, or because the scale of the failure is small. The last post I wrote on using scenarios for experiment design can help you identify these aspects, too.
An even better thing to do is to let someone else examine your ideas for experiment. Cognitive Edge’s Ritual Dissent pattern (requires free sign-up) is fantastic for that; it’s very similar to the Fly-On-The-Wall pattern from Linda Rising and Mary Lynn Mann’s “Fearless Change”.
In both patterns, the idea is presented to the critical group without any questions being asked, then critiqued without eye contact; usually done by the presenter turning around or putting on a mask. Because as soon as we make eye contact… as soon as we have to engage with other people… as soon as we start having a conversation, whether with spoken language or body language… then we automatically start seeking consensus.
And consensus isn’t always what you want.
All the great ideas are just that… great ideas… unless you can put them into practice.
I tell my team all the time that unless we can sell an idea to an executive… and know exactly what we’d do the next day if we sold it… it’s probably not worth talking about. At least not right now.
That’s not to say that we don’t run experiments. That’s not to say we don’t try new things.
There is a lot of neat theory out there… but unless you can get someone to sign up… it’s tough to make a dent.
You have to be able to sell it…