Professional athletes watch slow motion video of their performances to find areas for improvement. Armed with this information they can then work on these weaknesses and improve their performance. When studying for an exam how do you objectively measure your... Mike Griffiths

The purpose of a Silo is to protect the contents from being disturbed or damaged from  external foreign bodies. Creating a Silo is reasonable if you are the farmer protecting your grain from insects but surely they are not necessary in an organisation where we should be supporting each other? Unfortunately working culture can be hostile and silos are everywhere. If we want start breaking down silos and seeing the openness required for an organisation to learn effectively we need find better ways of treating each other.

Silos are destroying our ability to work effectively together. Silos allow people inside to hide their activities from the outside, whilst this protects us from judgment when something goes wrong it also protects us from vital feedback resulting in us spending much of our time doing the wrong thing.  Silos allow us to carry on working with dysfunctional relationships. Silos hide corruption and abuse. Silos are everywhere and we take them for granted, they are killing our organisations large and small.

Agile Development and the extended learning organisations requires openness. At first glance a Scrum team may look like a Silo, we protect the team from outside interference. But Scrum teams are different because they are (or should be) open. The reality of our work at any time is exposed on a large board that anyone can see. Our daily standup should be able to be viewed by anyone. Openness means if we are doing the wrong thing someone can tell us about it, if they care.

But have you noticed how most people don’t care? It’s because other departmental silos are protecting themselves from the reality around them, preferring to live with a more idealised view of how others should be working, and blaming when the ideal fails to materialise. A common example is Sales teams rarely pay attention to how product development is actually progressing preferring to rely on a fictitious plan. Managers often prefer to see a whitewashed report rather than gritty reality. When reality does finally unravel we respond with blame, punishment and sackings giving us good reason to reinforce our silos

So what can we do to get the openness and collaboration with the rest of the company that product development desperately needs?

Silos protect people from hostility so if we want to remove them we must stop treating each other in a hostile way. The way people treat us depends largely on the way we behave towards them. You cannot expect somebody who you judge and blame to be open with you about their needs. The sales team will not openly share with me what their customer’s need if I accuse them of selling the wrong thing. Their life is difficult and full of failures, if we want them to be open we must first empathise and once we understand the problems they face we can start to develop the trust that is required for effective collaboration.

Is there anything else we can do that will help others be more open with us? How about being welcoming? Showing appreciation? Is there anything we can stop doing that will help others be more open with us? We need to stop blaming. When we are asked an unreasonable request we need to stop putting up with it and becoming frustrated and resentful, we need to take the time to explain and together, discover better ways of working.

This is the kind of behaviour that could spread but it needs to start with us.

Emergent design is not something you do because you are doing Agile and you don’t have any choice because you don’t understand what you need to build.  Emergent design is a better way to design – even when you know what you want your system to do. I’ll admit I didn’t understand this until about 12 years ago.  I was in a situation where I understood what I wanted my system to do, but I couldn’t...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

I just entered a new post on an internal Yammer network. Writing the post took some time as it was one of the longer ones. When I tried to post it, Yammer told me that it (Yammer) had been update and needs to reload.

Result: The post was gone.

It appears as if Yammer is somewhat behind technologically. It should not lose content. GMail saves regularly and I have never lost an email that I hadn’t sent yet.

Recommendation: Use a text editor to create the post. Once you are good to go, reload Yammer, then copy the text into the browser window, and then post. This should avoid the duplicated effort of writing the post.

Agile teams find a lot of benefit from external coaching. Especially teams who, for whatever reasons, have not been focusing on continuous improvement. In my experience as an Agile coach, I've come across many situations where I could add value as...

Most people like short things: short tasks, short emails, learn-how-to-program-java-in-24-hours books, lose-weight-in-a-month video guides. Modern society is cursed by impatience and time pressure. Information flows hit us from all sides and we just can’t resist. We spend more and more time on shorter and shorter things.

Software development demands focus. You can’t create anything significant hopping from one thing to another. That is obvious. Less obvious is that product development demands patience.

Service development is different. In most cases you have a project with a visible end. It may be a year long, or even several years long. But still project will be completed someday… Or abandoned. Most service products are sprints. Clients pay you money and they want to have something as soon as possible. They radiate the impatience. They set deadlines. They resist to invest much into good engineering practices like automated tests. Yes, you negotiate all that and sometime with a success, but still it’s quite hard to sell a great development process to the customer. So you rush, cut corners, drop some good practices to save time and argue about change requests. Agile approach helps to solve some of these problems, but you still feel the constant pressure. And rush anyway.

This strategy doesn’t work for product development. It takes a decade or more to create a truly remarkable product. Constant rework, constant improvements, constant polishing and learning. You fail, learn something new, improve things and move forward. It just can’t be done without patience.

Suddenly you understand that great thing takes time and it changes your attitude. You learn how to run with a steady pace, maintain energy level and endure the race. In a sprint you have no room for any mistake. Even a little mistake will cost you huge. In a marathon you have time to fix problems and still win.

If you are in a product development business, I can give you several advices:

• Learn how to learn. This road takes many years, you need knowledge to solve problems and invent things.
• Learn how to wait. It is so fucking hard to me. Sometime I feel enormous pressure to speed everything up and run at a full speed. But I realize that it will drain all our energy and development team will be exhausted and washed out. We’ll start to lose people. Morale will go down. That’s not a viable strategy.
• Embrace re-work. Most likely you will have to re-write some parts of the system 3-7 times in the next several years. You should be ready to do that. Re-work is good. It makes things better.
• Ship early. You may think that now I’m a 100% perfectionist who will kill for the 1px design mismatch in a latest release. That is far from true. I like to ship things as early as possible to some closed group of customers at least. For example, we are working on v.3 of our product during the last 15 months. It is still not public. However, we had first users 9 months ago. Currently around 600 people from 100 companies are using v.3, we have constant feedback and make improvements based on it.

Remember, that most people can run a 100 m distance, few people can run a marathon.

Distributed Continuous Integration

I recently defined Continuous Integration as the practice of merging development work with a Master/Trunk/Mainline branch constantly so that you can test changes, and test that changes work with other changes, this is the "as early as possible" integration methodology. The idea here is to test your code as often as possible to catch issues early (Continuous Delivery vs Continuous Deployment vs Continuous Integration)  

Watching a presentation by Jez Humble of ThoughtWorks, who defines Continuous Integration (CI) in relationship to Continuous Delivery, I realized that my definition was in direct opposition to 2 minutes of his presentation: http://www.youtube.com/watch?v=IBghnXBz3_w&feature=youtu.be&t=10m  But why is Jez so adamant about these points, whereas I feel I am doing CI without everyone committing to a Mainline daily, with having Feature branches and often with working locally, making commits without having ALL integrated tests running.  Can I be?  I say yes, and the reason is because of where the integration points are and what kind of code is moving forward to Mainline - unstable code or stable code. These differences keep a clean stable Mainline which in turns gives the ability to deploy code to Production anytime.  Jez’s definition of CI (Centralized CI) causes bottlenecks and is in direct contradiction with the process of Continuous Deployment (CD), whereas Distributed CI is able to remove these barriers while still giving confidence good code is moving to Production.

Argument

The argument goes, that a Continuous Integration process is the process of constantly integrating all development work across the entire project into Mainline to detect issues early on in a code’s lifecycle.  I argue that when utilizing Continuous Deployment, this is detrimental and the proper way is to integrate only Production ready code to Mainline, while merging Mainline back onto the isolated development work.  Recently, I explained this concept to another developer and their response: “I have never thought about merging backwards from master to branches in order to run test, amazing”.  Continuous Deployment is not achievable using traditional CI methodologies as described by ThoughtWorks and others because the bottlenecks will prevent the flow of code from developer to Production, but the simple notion of merging backwards to run tests in order to see a view of Mainline before you integrate upwards, will allow you to achieve Continuous Deployment

Daily Commits to Mainline

Checking in only stable code is necessary for Continuous Deployment, however it is in direct opposition of the Centralized CI evangelists’ rule #1: (http://www.youtube.com/watch?v=IBghnXBz3_w&feature=youtu.be&t=10m) you must check into Mainline daily.  The idea here is that you are integrating with all development code daily, whether it is Production ready code or not.  This means that development work must be hidden if released, but it also means that development work, that may be thrown out tomorrow, may not integrate properly with Production ready work today, causing an unstable Mainline.  Any practice that forces Mainline to become unstable worries me a little, it just seems unnecessary.

In Distributed CI a developer commits locally to the developer branch and integrates often (daily) backwards from Mainline, saving the trouble of integration bottlenecks in Mainline.  Anything a developer takes from Mainline in a Distributed CI process is considered stable and releasable code - maybe not immediately used code.  Centralized CI may have a good build but still may have unreleasable code.  You must coordinate the Centralized CI release, a Distributed CI release does not have this issue, since Mainline is always considered stable and a release may be performed at anytime.  

Broken Builds

Oh and lets not forget broken builds - broken builds prevent anyone from being able to reliably take code from Mainline or move code to Production from Mainline.  Centralized CI has a way to “fix” this, rule #2: (http://eugenedvorkin.com/10-continuous-integration-practices/) never break the build, if you do you must fix it, and not leave until you do.  OK, so nevermind the insanity of the first part of this rule, since the only way to ensure satisfying it is by never committing: I cannot control how my code integrates with other unknown code..  And sure, if I break something, I understand that I must fix it.  But how do we know it was my code that broke the build and not yours, we don’t.  But assume it is me who broke it, now everyone is waiting for me to fix it.  I have now become a bottleneck and no code can move past Mainline, shoots, I guess Friday night beers are not in my future.  And the pipeline from developer to Production has just halted dead in its tracks, no code can be Continuously Deployed.  Some places call this a lesson (http://www.hanselman.com/blog/FirstRuleOfSoftwareDevelopment.aspx) and assume that you will learn from this ordeal, I think you will fear it, yes, but to work in fear . . . I prefer not to.  I prefer to have systems that do require me to stay late to keep Mainline stable unduly, but rather a system that always ensures Mainline is stable, before and after my code is merged.

Distributed CI deals with this with a “mergeback” from Mainline to your developer branch - ensuring that you have a clean build after running unit tests on the branch, then merging up to Mainline. Otherwise, having failed a developer branch unit test - do not merge to Mainline, do not become the bottleneck, go out for beers, rest well, and fix it tomorrow.  After the developer branch is merged to Mainline, do not run the unit tests again - the test suite was already run against a copy of Mainline in your development branch, already knowing that all tests have passed, the code is deployed right out to Production.  Then Mainline is merged backwards to other developers’ branches, and unit tests are run individually on each developer branch.  If any tests fail - the owner of that branch must fix the issue.

Feature Branches

Rule #3 (http://www.youtube.com/watch?v=IBghnXBz3_w&feature=youtu.be&t=11m49s minutes 10-12 are definitely my favorite) - no feature branches.  Wait what? Hold on, I like my feature branches.  But Jez did just say: “But you can’t say you’re doing Continuous Integration and be doing feature branching. It’s just not possible by definition (while waving hands)”, didn’t he?  Looking at the definition of CI from Martin Fowler of ThoughtWorks:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.  (http://martinfowler.com/articles/continuousIntegration.html)

I do not actually see anywhere that says CI cannot have feature branches, just that all developers work must integrate frequently - not even daily.  Well in Jez’s Centralized CI - feature branches are a no go - you must integrate daily ALL changes to a centralized Mainline.  But hold on - this code can’t be integrated into Mainline, its weeks away from delivery.  In distributed CI - a feature branch is nothing more than a developer’s branch.  Feature branch away. Mainline will be integrated back into the Feature branch after any Production deploy and all new stable code will be integrated and tested immediately.  

Hmmm, sounds like feature branching and CI are not mutually exclusive - nice. But Jez was very clear on this.  Yes, his worry is about long running code not being integrated with.  OK - so you want a true feature branch and not integrate up to Mainline for longer than today.  Well you can.  Since you are always integrating backwards from Mainline.  But you must continually do this.  Once we are ready to move the feature branch into Mainline - we already have a snapshot of what Mainline would look like, the feature branch is Mainline plus all new code of the feature branch, and it has been Continually Integrated with since creation every time Mainline is updated.  If two developers want to integrate with each other, then they are able to in the Distributed CI World, they can actually be moved behind another integration point, where their work is merged up to it and then to Mainline.  This is basically utilizing the ability to create a distributed network of developers working off of various localized Mainlines that merge up to a Master Mainline.

Distributed CI Reigns Supreme with CD

Distributed CI has the advantage for Continuous Deployment because it keeps a clean and stable Mainline branch that can always be deployed to Production.  During a Centralized CI process, an unstable Mainline will exist if code does not integrate properly (broken build) or if there is unfinished work integrated.  This works quite well with iteration release planning, but creates a bottleneck for Continuous Deployment.  The direct line from developer branch to Production must be kept clean in CD, Distributed CI does this by only allowing Production ready code to be put into the Mainline.

Is Distributed CI really CI?

Yes.  if you are implementing Distributed CI and CD together, you will always be integrating your developer code with the latest stable release to Production.  If an integration test fails after the release to Production, it will fail for a developer’s branch, not everyone, so we know the integration failure is isolated to that developer’s branch and the new code; the developer whose failed branch must attend to it.  In Centralized CI, the developers must discuss and work out this issue to see who is at fault.  CD demands that you deliver code to Production often.  In Distributed CI, anytime you deliver code to Production, the Mainline branch is merged back to developer branches and tested (thank goodness for automation).  What does this mean, lets look at the life cycle of a commit a little closer:

The top diagram shows a Centralized CI process, where the developer merges into a Mainline integrated with other developers commits before running Unit Tests.  Mainline cannot necessarily be deployed since some work from developers may not be Production ready.  The lower diagram show a Distributed CI process where the developer merges Mainline backwards, then integrates up to Mainline, then pushes on through to Production.

If you are performing CD, you are releasing very often, each stable commit is still tested with every developer’s development work.  Except in distributed CI - its tested individually, so detection of issues is easier - the amount of conflicting code is less, and isolated - to a developer’s branch.  Distributed CI is a more thorough form of CI when implemented with CD - which attempts to break down processes into smaller automated pieces.  Centralized CI is suited for iteration release planning, but distributed CI will work just as well for this and better.  If you are doing centralized CI - then you are not doing Continuous Deployment.  Dstributed CI removes all the bottlenecks and constraints placed on the workflow from developer to production that centralized CI requires.  

So why all this confusion around CI and the artificial constraints put on it?  Clearly, the centralized VCS is the basis for these constraints.  Basically, Distributed CI is treating each developer branch like it is Mainline and testing there instead of up to a centralized Mainline.  Perhaps its because CI grew up in a time of non-distributed VCS and has not modernized since.  Now is the time to utilize the advantage of a distributed VCS.  Unleash those feature branches, and commit code now, merge to Mainline to see it in Production moments later - yes, moments later, every time.

Anyone else performing CI like this, or have any other questions, please leave a comment below.

To read more about Continuous Deployment and how it can help you, check out Assembla and CD.

How long does it take an organization to reorganize in order to adopt Scrum? Three hours. Really. Background and goal Bank of America's Merrill Lynch (BAML) Global Securities Operations Technology decided to adopt Scrum and needed some c...

Am Wochenende hielt ich die iPad-App der Süddeutschen Zeitung in meinen Händen und spürte: Das ist es.

 

Ich weiß noch genau, wie ich vor zwanzig Jahren die allererste Internet-Verbindung mit meinem Telefon-Modem und einer lokalen Einwahlnummer aufbaute. Die erste Seite, die ich damals im Web aufrief, war: http://www.spiegel.de. Texte und Bilder bauten sich langsam, Zeile für Zeile auf, und in dieser einfachen HTML-Sprache gab es nicht viel mehr außer Texte, Bilder, und klobige Frames. Die Seite war etwa zur Hälfte aufgebaut, dann brach die Verbindung ab. Ich bewahre den Screenshot von meinem ersten Mal noch heute auf. Als Dreizehnjähriger konnte ich damals kaum schlafen vor Aufregung, war ich doch in das World Wide Web vorgedrungen.

 

Was damals für die Verlage als einfache Web-Präsenz mit minimaler Investition anfing, ist heute nicht mehr wegzudenken. Weil viele Printmedien immer härter um ihre Leser kämpfen müssen, ist das Online-Geschäft zum Hoffnungsträger mutiert. Dass sich mit Online-Anzeigen nicht viel Geld verdienen lässt, ist keine Neuigkeit. Ebenso wenig scheinen Leser in der Masse bereit zu sein, für den Aufruf einzelner Nachrichten im Web Geld zu bezahlen. Dafür sind Nachrichten allgegenwärtig, der Zugang zu ihnen bietet keine privilegierte Erfahrung mehr.

 

Was waren das noch für Zeiten, als man seine Zeitung im Kiosk kaufen musste (allein schon der Weg dorthin eine Investition!) und man sie dann, das Papier unterm Arm eingerollt, in Cafés und auf der Straße zur Schau stellen durfte. Als man die Seiten genüsslich, fast theatralisch aufspannen konnte. Im vollen Bewusstsein darüber, dass dieser Text, diese gedruckten Buchstaber, Bilder und Wörter, nur auf dem Zeitungspapier Sinn und Form ergaben.

 

Den Zauber zurückbringen – mit gutem Design

Vor diesem Hintergrund muss die Entwurzelungen des Wortes vom Papier hin zur neonkalten Web-Seite ein Sündenfall gewesen sein: Mit dem Verlust des Papier-Privileges waren Zauber und Einzigartigkeit der Printmedien vorüber. Umso erstaunlicher nun die Renaissance: Eine gut gemachte Zeitung wirkt auf dem iPad nicht nur schick, sondern begehrenswert. Schriften, Bilder und Layout fügen sich zwanglos in den formvollendeten Rahmen. Die Navigation ist leicht und intuitiv. Das Scrollen mit dem Finger macht Spaß. Und die Interaktivität (Video, Audio, Bildergalerien) wirkt nicht aufgedrängt, sondern wie natürliche Verlängerungen. Auf dem hauchdünnen Touchscreen aus Glas sieht die Zeitung – ich traue mich fast nicht, es zu sagen – lebendiger, ja wirklichker aus als auf Papier.

 

Offenbar wird die Bedeutung von Design noch immer unterschätzt. Auf Projekten erlebe ich irritierte Product Owner, die nicht verstehen können, warum die Benutzer ihrer Software zur Konkurrenz wechseln wollen, weil sie deren GUI „schöner“ fänden. Aber geht es wirklich um Kosmetik, um das pure Aufhübschen und Aufbauschen? Könnte es nicht vielmehr sein, dass sich gerade dort, in ganz prosaischen Tätigkeitsfeldern wie etwa Kundenmanagement oder Abrechnung, der müde Sachbearbeiter nach einer übersichtlichen, leicht zu bedienenden und schicken Bedienung sehnt? Vielleicht könnten wir das Leben überall verbessern, wenn wir uns nur etwas mehr um besseres Design kümmern würden.

 

"Design is a plan for arranging elements in such a way as best to accomplish a particular purpose." Charles Eames

Related posts:

1. 5 min on Scrum | Scrum and Design
2. Design by commetee
3. Design eines großen Systems – Tom DeMarco

Here are 10 articles from 10 different authors that provide valuable advice for Scrum teams. These articles are in no particular order, so feel free to skim down the list and start with the ones that are most relevant to you.

1. 10 Tips for a Great Daily Scrum Meeting by Platinum Edge – The daily Scrum meeting is a powerful tool that keeps your project moving. At the same time, it is also easy for the meetings to not bring any added value.
2. Tips for Effective Backlog Grooming  by Charles Bradley – Are you wasting time in your Sprint Planning Meetings? Increase the value of your team’s Sprint Planning Meetings by grooming your Product Backlog.
3. Yoda’s top 10 tips for a new Scrum Master by Nigel Steane – As a new Scrum Master, you face unfamiliar challenges and your success is very much based on your ability to utilise coaching and soft skills to gently guide your team and colleagues.
4. Top ten tips for distributed Scrum team teleconferences By Jon Archer –  After acting as a Scrum Master for several months on a distributed team with people in six different locations, three different countries, learn ten tips to help get past those inevitable awkward silences.
5. 10 tips for adopting Scrum to save your project by Matthew Hodgson – Are you interested in adopting Scrum for your next project? Here are 10 tips from his experience with moving a number of projects from their existing project management frameworks to Scrum.
6. Five Tips for Impediment Resolution with Scrum by Stefan Roock – Impediments can slow down or even halt the progress of an otherwise well-functioning Scrum team. Take a look at the most common challenges that crop up on teams and what steps you can take to resolve them.
7. 10 Tips for Succeeding with Enterprise Agile Development by Tools Journal – Many enterprises are experimenting with agile development approaches like Scrum, Kanban, Lean, and XP hoping that introducing a new development approach will help. Yet, agile development has struggled to achieve critical mass in large enterprises.
8. 6 Tips for Good Scrum by Martin Harris – If you are doing these 6 tips, then you are doing very well and are likely to get better over time.
9. 9 Tips for Creating a Good Sprint Backlog by Luciano Felix – Giving attention to the sprint backlog creation process is fundamental to the team’s understanding of what should be done and how to better plan during the sprint.
10. 7 Tips for a More Effective Daily Scrum by Richard Lawrence – The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. Here are seven ways to get your Daily Scrum back on focus If your it has become unfocused, too long, or otherwise ineffective.

If you have any other good articles related to agile, please share them in the comments. Thanks.

94 Expert Tips For Agile Teams was originally posted on Axosoft's blog.

This is the second issue of James Brett‘s 5 Questions. From the first issue of 5 Questions ”The ideas was to ask five specific questions to members of the Scrum community and post the their replies.”

Over the next couple of months I’ll be republishing all of James Brett’s 5 Questions as they appeared on his blog.

In issue 2 of the five questions series we hear from one of the godfarthers of Scrum Ken Schwaber. Ken (along with Jeff Sutherland) is responsible for creating Scrum way back in the day, not only that but Ken created (or helped create) the Scrum Alliance and the Agile Alliance. Ken has produced three Scrum books that have guided so many people through the Scrum framework. So without further ado. I give you the man himself….Ken Schwaber!

Bio. I have been in software development for over thirty years, starting as an operating systems programmer. I have held positions ranging from bottle washer to cook, waiter to restaurant manger. I was a signer of the Agile Manifesto and started the Agile Alliance and the ScrumAlliance. I co-developer Scrum with Jeff Sutherland and have spent the last seventeen years understanding what it means and how to use it better. I live in Lexington, Massachusetts with my wife, Christina.

Ken’s answers..

Q1. Can you describe what you would consider the top Scrum enabler in an organization?

A passionate desire on the part of the people to do their best.

Q2. Where do you see Scrum in 5 years time?

Like Lean, except for complex development. If an organization’s people use Scrum to improve their product development practices and people, others will be unable to compete with them.

Q3. What has been your toughest Scrum challenge so far?

Undoing the habits that come from predictive processes, such as waterfall. People of my generation have this drilled into them so that, under stress, they revert to its thinking as “the thing that has always worked for me.”

Q4. What makes you passionate about Scrum?

Scrum is a framework for people to apply their maturity, intelligence, and professional skills to make their lives, their organization, and society a better and more fulfilling place to be. What more can you ask from life?

Q5. What can we learn from you about Scrum?

That change is hard and the rewards are worthwhile. What better way do we have to spend our lives?

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

When adopting agile as a product development methodology, the organizations wouldn’t forget to manage their portfolios accordingly. It happens frequently that when organizations want to adopt agile, they think it’s only a matter of introducing just one more new methodology in the “assembly line”. They wrongly imagine that it’s only a matter of having the [...]

I got an email this morning from our Community Manager listing all the agile events we’re doing this spring and wow – we’re gonna be busy! Scope out the list…

Is one of these events in your area? Come out and see us. Don’t give a crap? Share this list with someone who might:

AgilePalooza Twin Cities. Private day @ Target on 4/11. Public day on 4/12. http://agilepalooza.com/mn2013/

ATL Javascript Group. Monday, 4/15 @ 7PM @ Ogilvy. http://www.atlantajavascript.com/events/81796572/

Mile High Agile: Denver, CO. 4/19 http://milehighagile2013.agiledenver.org/

PMI Region 6: St. Louis, MO. 4/19 – 4/21 http://www.stlpmi.org/

LeanKanban 2013: Chicago, IL. 4/29 – 5/1  http://lkna.leankanban.com/

PMI Nashville: Nashville, TN. 4/29 – 4/30

Project Management Symposium: Innovating the Future. http://www.pminashville.org/downloads/newsletter/doc_download/84-symposium-flier-with-schedule

PMI Augusta: Augusta, GA. 5/2 – 5/4

PMI Region 14 Leadership Conference. TBA.

Kansas City Developers Conference. 5/3 – 5/5. Kansas City, MO http://kcdc.info/

Scrum Gathering Las Vegas. 5/6 – 5/8.  http://www.scrumalliance.org/events/610-las-vegas-

AgilePalooza Seattle. Private day: TBD — 5/16.  Public day:  5/17 Seattle, WA http://www.agilepalooza.com

Gartner PPM Summit. 5/20 -5/22 Washington, DC http://www.gartner.com/technology/summits/na/program-management/

Path to Agility. 5/22 and 5/23.  Columbus, OH.  http://www.thepathtoagility.com/

ADP West. 6/3 – 6/7. Las Vegas, NV. http://adc-bsc-west.techwell.com/

 

Catch a complete list of all agile community events or list your own event at AgileSherpa.org.

The Scrum Primer is an in-depth introduction to the theory and practice of Scrum, and includes data on results from a large-scale corporate adoption of Scrum. Its authors are Certified Scrum TrainersGabrielle Benefield,Pete Deemer,Craig Larman, andBas Vodde. You can download the Scrum Primerhere.

Bevor ihr meinen Artikel lest, lest mal das hier:

“Why firing brilliant assholes is required to build a great engineering culture”

Ein interessanter Artikel, den ich an vielen Stellen unterschreiben kann. Nur an einer nicht:

“A lot of people say don’t fire great engineers – but they’re wrong. Even if you have an engineer who is exceptional, but an asshole, you should fire them immediately. Your team will thank you for it afterwards. It only takes one asshole to destroy an entire team, so act quickly and remove any bad seeds no matter how good they are at writing software.”

Ich frage mich und die Teams immer, warum sie es sich gefallen lassen, dass jemand im Team sich wie ein A******* benimmt? Warum wehren sie sich nicht? Da sitzen dann teilweise 5 bis 7 erwachsene Menschen und lassen sich von einem tyrannisieren? Und der ScrumMaster oder besser noch der Manager soll es  richten. Ich frage dann, welchen versteckten Gewinn sie durch das Leiden haben. Da ernte ich meistens verwirrte Blicke. Eigenverantwortung heißt, für mich und meine Befindlichkeit die Verantwortung zu übernehmen – in jeder Situation. Finger Pointing und Jammern haben noch nie langfristig geholfen. Und unterstützen nicht gerade die Eigenverantwortlichkeit. Der andere, die Umstände sind schuld, die Manager sowieso und die Welt ist ungerecht.

Wenn ich mir so ein Verhalten gefallen lassen, ist meine erste Frage an mich: “Warum tue ich das?” Und die Antwort ist oft nicht schmeichelhaft. Ich scheue den Konflikt und warte bequem drauf, dass es ein anderer richtet. Jeder von euch kann es mal an sich selbst ausprobieren.

Fragt euch selbst: “Warum lege ich mich mit diesem oder jenen Ekelpaket nicht an?” Und seid ehrlich zu euch, ihr müsst es niemandem erzählen ;-). Der Selbstausdruck wird verhindert, weil man nicht bereit ist, den Preis dafür zu bezahlen, also aus Angst vor Zugehörigkeitsverlust, Konformismus, Angst vor Konsequenzen usw. Aber das hat meistens nichts mit dem anderen zu tun, er triggert es nur unbewusst an.

Sind Assholes Ursachen oder Symptome?

Eine andere Frage ist, ob das identifizierte “Asshole” wirklich der Grund ist … oder nur ein Symptom? Ein Symptom für ein Machtvakuum, ein schwaches Team etc. In der Psychologie spricht man vom identifizierten Patient. Ein ganzes System – eine Familie z.B. – ist aus dem Gleichgewicht, der Vater ist Alkoholiker, die Mutter hat Depressionen und das Kind ADHS. Aber nur der Zappelphillip bekommt Ritalin, weil das andere unsichtbar bleibt hinter der Fassade. Hilft das der Familie?

Ich schaue als Agiler Coach also gerne hinter die Fassade und sehe mir den Konflikt näher an. Was ist da wirklich aus dem Gleichgewicht geraten? Und welche Bedürfnisse stecken hinter dem Verhalten des auffälligen Teammitgliedes? Merkt er es überhaupt (auch das habe ich schon erlebt, der Betroffene war sich seiner Außenwirkung gar nicht bewusst). Und warum wehrt sich niemand? Es gilt, nicht Konflikte zu vermeiden, sondern sie fruchtbar zu machen und das heißt eben manchmal auch, sie richtig hochzufahren.

Ich bin keine Freundin der Konfliktvermeidung. In Konflikten steckt Energie, zwar verzerrt und irgendwie verhindert, aber sie ist da. Deckt man nun den Konflikt zu, schafft man es nie, diese Energie zu erlösen. Viele Märchen handeln davon, zum Beispiel das Märchen vom Froschkönig. Hier taucht ein hässlicher Frosch auf, der sich später als verwunschener Prinz darstellt. Übertragen bedeutet das: Hier kann ein Potential nicht gelebt werden. Die Prinzessin im Märchen will den hässlichen Frosch zwar loswerden, aber der kommt immer wieder. So ist es auch mit Konflikten, die man ignoriert. Man kann Konflikte einfach nicht wegmachen oder ignorieren. Sie kommen mit geballter Macht zurück und entladen sich destruktiv. Man kann nur genau auf das hinschauen, was da gerade passiert.

Dafür gibt es ein paar wichtige Regeln:

• Wertschätzung und Respekt vor dem anderen sind die Basis.
• Jeder übernimmt  für sich und seine Befindlichkeit die Verantwortung.
• Respekt davor, dass ich die Situation anders erlebe als der andere – niemand hat Recht.
• Jeder spricht von sich – rede ich vom anderen bin ICH nicht anwesend.
• Es gibt einen Raum jenseits von Falsch und Richtig – ich nehme auf, ohne zu werten.

Wenn sich das Team auf diese Regeln verständigen kann, entsteht meist von ganz allein ein Lösungsprozess. Viele Konflikte sind einfach gestörte Kommunikation. In dieser Haltung der Achtsamkeit füreinander kann man gemeinsam eine Vision entwickeln, wie man als Team zusammenarbeiten möchte. Um diese Haltung einzuüben, mache ich am Anfang oft eine einfache Übung. Jeder darf eine festgelegte Zeit erzählen, wo ihn gerade der Schuh drückt. Meistens reichen 2 bis 3 Minuten. Wichtig ist, die eigene Befindlichkeit mitzuteilen – kein Finger Pointing und die anderen hören zu. Aufmerksam, achtsam und achten darauf, was bei ihnen selbst passiert.

Danach entwickle ich mit den Teams eine Vision, wie die Teammitglieder zusammenarbeiten wollen. Es geht, wie so oft bei Scrum, um die Vision. Nicht darum, sich mal allen Ärger und Frust von der Seele zu reden und ihn sich gegenseitig an den Kopf zu werfen. Das ist oft destruktiv und kontraproduktiv. Also kein Gewitter, bei dem mal alle Energie entladen wird und es laut wird. Die im Konflikt gebundene Energie sollte befreit werden und auf ein gemeinsames Ziel gerichtet werden. Im Märchen küsst die Prinzessin den Frosch  - und schwupps – steht ein wunderschöner Prinz vor ihr.

Also küsst eure Konflikte wach 

Related posts:

1. Schätzen vs. Planen?
2. Warum keine Tasks im Backlog?
3. Der ScrumMaster – Führung

Getting things done is great; to get things done is why we start things in the first place and why we follow through even when presented with obstacles and setbacks. We do things because they will (hopefully) bring us to... Mike Griffiths

After my GDC presentation on Kanban for production, a question came up about having a board, which models a value stream that produces a variety of assets.  It was a good question, but I didn't have the time to answer it as thoroughly as I'd like, so I thought I'd do so here.

In the presentation, I started with describing a simple flow, such as the flow of drinks at Starbucks.
Starbuck's Kanban
If you are a coffee drinker who frequents Starbucks, like me, you probably appreciate that you don't have to wait for all the lattes, cappuccinos, etc ordered ahead of you to be made first.  This is because the barista is working on those exclusively and the cashier can directly pour your coffee for you.  Looking at the Kanban board above, my coffee goes from the "order" column to the "leave" column directly.
This benefits everyone.  As I mentioned in the talk, a key metric for Starbucks is the customer cycle time: the amount of time it takes between walking in the door and when you walk out with your drink.  The critical path for coffee drinkers and latte drinkers isn't the same, but it isn't entirely separate;  Much as I personally would enjoy it, there is no separate cashier line for coffee drinkers. Starbucks has chosen not to optimize specifically for us, for good reason.
This is similar to the approach you might use for mixed asset types.  Although every asset will have a large variation of effort needed and partially separate paths, measuring every asset's cycle time will still give us valuable information.  The goal isn't to achieve a uniform cycle time for all assets; Just as people who order lattes should expect to wait longer at Starbucks than us super-efficient coffee drinkers.
Let's look at the Kanban board that shows various assets going through a production pipeline:A mixed asset Kanban board
This board includes assets that might need particle FX or animation applied to them, or neither.  The important principles apply.  We're going to measure the throughput and limit the work-in-progress (WiP) regardless of which steps are taken.  Some assets will skip some steps like me skipping the barista.  Doing this can improve the entire system.  As a coffee drinker, I don't care how quickly the barista can make a latte, but I greatly appreciate when the under-tasked barista helps fill coffee orders.
This can happen in an asset production pipeline as well.  As we measure throughput, we can create such policies in a production pipeline:  Starbucks has far shorter coffee cycle times than barista-drink cycle times and that is fine for everyone.  The key is to measure throughput for different asset classes and explore where and when improvements for classes can improve their cycle time without impacting the other classes.
Most production pipelines are far more complex than this, but the same principles apply.  Start by simply modeling what you're doing now.  Then measure throughput and reduce WiP.
...and don't be surprised that as you try to improve your existing overloaded hetrogenous pipeline that the conclusion you arrive at is that maybe the assumptions of the pipeline need an overhaul!

A lot of folks in the agile community feel like projects and project managers are a big part of the problem we have delivering software. My view is that projects are not really the problem… it’s projectized organizations that are the problem.

Projectized organizations form when we have people organized into functional silos and assign them as necessary to project work. The underlying assumption is that people are fungible resources and can be split indefinitely across projects to get work done.

Agile methods take a different approach. People are organized into cross-functional teams and focused on a product… or a set of features… or a component… or a set of services… within the larger production ecosystem.

Projects as a funding vehicle in most organizations are just fine. The shift in thinking is that projects have to be broken up and funneled through teams. Each team is responsible for a subset of the project deliverables with integration happening on regular intervals

I’d much rather integrate the work of many teams producing working tested features than try to integrate the activities of many individuals working within their own particular speciality. Done is easier to see and bottlenecks are easier to identify and resolve.

This is the #1 biggest problem we see with organizations trying to adopt agile. They do not have a pattern for organizing teams and managing project deliverables across teams. Until this gets sorted out… you are not likely to have much success using agile at any scale.

The post Projects Are Not The Problem appeared first on LeadingAgile.

Here are 10 articles from 10 different authors that provide valuable advice for Scrum teams. These articles are in no particular order, so feel free to skim down the list and start with the ones that are most relevant to you.

1. 10 Tips for a Great Daily Scrum Meeting by Platinum Edge – The daily Scrum meeting is a powerful tool that keeps your project moving. At the same time, it is also easy for the meetings to not bring any added value.

2. Tips for Effective Backlog Grooming  by Charles Bradley – Are you wasting time in your Sprint Planning Meetings? Increase the value of your team’s Sprint Planning Meetings by grooming your Product Backlog.

3. Yoda’s top 10 tips for a new Scrum Master by Nigel Steane – As a new Scrum Master, you face unfamiliar challenges and your success is very much based on your ability to utilise coaching and soft skills to gently guide your team and colleagues.

4. Top ten tips for distributed Scrum team teleconferences By Jon Archer –  After acting as a Scrum Master for several months on a distributed team with people in six different locations, three different countries, learn ten tips to help get past those inevitable awkward silences.

5. 10 tips for adopting Scrum to save your project by Matthew Hodgson – Are you interested in adopting Scrum for your next project? Here are 10 tips from his experience with moving a number of projects from their existing project management frameworks to Scrum.

6. Five Tips for Impediment Resolution with Scrum by Stefan Roock – Impediments can slow down or even halt the progress of an otherwise well-functioning Scrum team. Take a look at the most common challenges that crop up on teams and what steps you can take to resolve them.

7. 10 Tips for Succeeding with Enterprise Agile Development by Tools Journal – Many enterprises are experimenting with agile development approaches like Scrum, Kanban, Lean, and XP hoping that introducing a new development approach will help. Yet, agile development has struggled to achieve critical mass in large enterprises.

8. 6 Tips for Good Scrum by Martin Harris – If you are doing these 6 tips, then you are doing very well and are likely to get better over time.

9. 9 Tips for Creating a Good Sprint Backlog by Luciano Felix – Giving attention to the sprint backlog creation process is fundamental to the team’s understanding of what should be done and how to better plan during the sprint.

10. 7 Tips for a More Effective Daily Scrum by Richard Lawrence – The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. Here are seven ways to get your Daily Scrum back on focus If your it has become unfocused, too long, or otherwise ineffective.

If you have any other good articles related to agile, please share them in the comments. Thanks.

Agile development is all about collaboration. The writers of the Agile Manifesto value customer collaboration over contract negotiation. There was definitely a sense that we had gone off the rails - that software development had become too much about contracts and too little about common-sense, face-to-face negotiations.

But if you think about contracts, they’re really just a tool to reinforce trust. I think of the Scrum process as a series of micro-contracts. In exchange for a promise to deliver a working piece of software in two weeks, a team is given great latitude to work the way they want to work. Each time a team delivers on their sprint goal, they reinforce the trust that the business has placed in them. A track record of 25 successful sprints over a year or so goes a long way to showing that a team can be trusted.

Step up a level to the product owner, though. In a larger enterprise, many product owners are prioritizing backlogs for many teams. A product owner working with two scrum teams is responsible for a $2M annual investment. That’s significant. What’s the right way for a business to protect itself from the risk?

Contracts.

An agile portfolio contract is a lightweight thing. It’s less than a hundred words long. It defines an initiative that is meant to take 3-6 months to complete, with one or a couple of teams. It includes a hypothesis about value (“if users can get instant credit decisioning more small business loans applications will complete”) a list of 3-5 measurable success criteria (“completion rate is doubled among users who get to step 4 of the loan”) and a list of assumptions to be validated (“we can get responses from the decisioning engine in less than 2 seconds on average”). It includes a cost (1 team for 3 months).

What it doesn’t include is a detailed, locked-in feature list. The PO needs to retain discretion on the features in order to be able to negotiate scope to meet the planned end date.

There are 2 ways a PO can come out as a winner in this contract:

• Deliver the succcess criteria before the planned end date
• Raise risks within the first month and renegotiate the contract

On the other hand, a PO who plans badly, defers risky work until late in the initiative, and doesn’t let stakeholders know until a month before the end (or worse, after the end), weakens the trust the organization has put in them.

In your organization, do your POs have specific, measurable goals they’re trying to achieve? Or have you just given them a blank check? It seems like the blank check approach is more agile, but in a large organization, it’s impossible to ensure that all of your POs are making good calls all of the time. You need a basic framework to negotiate with them, and to build up that trust. PO fails to deliver on a 6-month initiative? Maybe next time they get 2 months to build their credibility back up.

At Rally, one of our core values is cultivating trust and respect. Trust is something that is continually built and rebuilt. Is your portfolio helping your POs to build trust, or are you setting them up to be less and less trustworthy?

Alex Pukinskis