Almost 500 pages…for the application…proof, proof, and more proof. 

If you are a trainer, and you want to become a PMI REP so people can claim PDUs for taking your class or workshop, you have some tree-choppin’ to do. Maybe the option to submit this in electronic form is better…way to go.

---

You just finished reading Becoming a PMI Registered Education Provider (R.E.P.) - More like RIP for Trees! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

I’m not sure whether I was offended or just… surprised. Happy Friday!

---

You just finished reading Slowest Email Response Ever [Friday Weird]! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

I’ve been to a couple AgilePalooza’s in my day. They rock. So get your butt over there if you’re in the Seattle area fo’ sho.

On May 16^th Dave Hussman of DevJam will deliver an agile keynote at AgilePalooza in Seattle. VersionOne has sold out the last few of these events, which bring the agile community together for a jam-packed day of low-cost agile learning in an informal, interactive format. Speakers are generally agile coaches, consultants, and otherwise butt-kickers in their knowledge of agile best practices.

Other guest speakers for this event include Tricia Broderick, Richard Dolman, Kevin Klinemeier, Michael Tardiff and others. Details, complete agenda and registration can be found here: http://agilepalooza.com/seattle2013/.

Stuff people say about AgilePaloozas:

Wow! This was the best Agile conference I’ve ever attended! You have provided an incredible value to attendees. Events like this show why VersionOne is one of the premiere brands in Agile Development. Thank you!” - Vivek M. Chawla

Exceeded my expectations – thank you so much! Great professional speakers, totally relevant topics; 100% applicable to my job.” - Michelle Walker

---

You just finished reading Get out to Seattle for AgilePalooza May 16th! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

Register for Upcoming Webinars

Topic: “Growing High Performance Teams through Coaching & Mentoring”

Presenter: Peter Saddington C.S.T

22 April 2013 • 12 PM – 1PM EDT

Abstract
Did you know that over half of Nobel Prize winners were apprenticed by other Nobel laureates? To grow companies and teams to performance you have to take servant leadership to it’s logical conclusion: Intentionally mentoring and growing others. This is a time-tested and practiced art. As a volunteer life coach and marriage counselor and Organizational Consultant, I’m passionate about this art and would love to share with you how to take your teams to the next level of performance. Let it be known, this is a long, tough road, but the benefits are worth more than their weight in gold. Let’s talk about mentoring and how to get started, the 6 areas of a mentor relationship and 6 tips for mentors.

About the Presenter
Peter Saddington co-founded a successful Organizational Design Consultancy and has been integral in multi-million dollar Agile Transformation projects with some of the biggest Fortune 500 companies, including Cisco, T-Mobile, Capital One, Blue Cross Blue Shield, Aetna, Primedia, and Cbeyond. He is a sought-after speaker at many industry events and is a Certified Scrum Trainer (CST). He has also received three master’s degrees, one of which is in counseling, and provides life-coaching services in addition to his consultancy.

---

You just finished reading Growing High Performance Teams through Mentoring [Webinar] 2013.04.22 at Noon! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

I opened this up in the office and I literally said out loud: “Oh my goodness. You’ve got to be kidding me.”

I assume it’s an April fools joke… but reading the comments on this video was even better than the video itself…

For example:

Don Draper 13 hours ago

---

You just finished reading Jira Jr. - Project Tracking for Kids? ! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

I know there are more than a few Agilists who are bloggers among us and even more than enjoy taking pictures of their families, friends, their work, and maybe even their food on occasion (admit it, you do it).

---

You just finished reading WordPress and Pictures [PressGram Kickstarter App]! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

Agile is a liberating way of working. It does not preclude the use of existing skills and knowledge. But it does require teams, users and stakeholders to adopt new ways of working together.

This short guide lists a few of the behaviours common to agile projects that support successful delivery and learning.

Understand your users

Prioritise features for them over everyone else – including your big, scary stakeholders, and seek their feedback early and often. Really listen to them. Even when they tell you things you don’t want to hear or disagree with. If possible, use data from real people using your product to influence the direction of the project. Your focus on the user should be relentless.

“What do you want next Friday? What have we learned last week?”

Iterate often. Build something focused on the next most valuable user need and show it to them; listen to their feedback and improve it. Keep doing this until you have something so useful that they would not be without it.

It perhaps sounds like over-simplifying the complexity of software development and project management, but at its heart this is what agile development is all about: “What do you want next Friday?”

The process of delivering incremental, production-ready software allows a team to deliver value to their users and stakeholders regularly. It shortens the feedback loops that might otherwise have been longer using a waterfall methodology. An iterative delivery cycle also forces the team to think about what the most important features are to deliver next and focuses the mind on useable software.

At the end of each delivery cycle, or sprint, teams should run aretrospective to review ‘what worked, what could be improved’ in the next sprint.

The software and the team continue to learn through delivery and iterate and improve throughout the project.

Small, agile teams

Small teams of between five to ten people are often more productive and predictable than larger teams. Forget man-days and think about the team as the unit of delivery.

A good team includes members with all of the skills necessary to successfully deliver software. A fully-functioning team has three key roles embedded into them, usually full-time:

Product Manager - responsible for delivering return on investment, usually by creating products that users love. The team delivers the Product Manager’s vision.

Delivery Manager (a.k.a. Scrum master or Project Manager) – is the agile expert that is responsible for removing blockers (things slowing a team down). They also usually act as a facilitator at team get togethers.

Team member - Self organising, multi-disciplinary team that delivers prioritised user stories. Responsible for estimation.

You help each other and work together toward delivering your sprint goals. It’s common to encourage team members to pair. It sounds counter-intuitive to have two people work on one thing, but this is not so. Working together closely produces better software solutions, promotes better quality controls and spreads knowledge across the team.

A good team can estimate their output, or velocity, very effectively and consistently. This allows for much more accurate planning.

Fail fast

Releasing little pieces of code often improves quality and visibility and reduces cost to market, but using agile techniques does not guarantee success. You can still fail! What agile methodologies do allow you to do is to spot problems earlier and resolve them.

Here’s a few examples of how:

• releasing working software to your users often allows you to get feedback quickly and hear or see what they think. If the product is wrong you can easily change direction and iterate.
• if your software is rarely released to production you are not demonstrating value to your sponsor. You run the risk of creating a “too-big-to-fail” service that isn’t fit for public consumption but must be released anyway. That means another press headline! Ship! Ship! Ship!
• if your teams’ velocity is consistently volatile, beyond the initial 4-6 sprints, then this is indicative of something that needs fixing. Perhaps there is hidden complexity or poor estimation.
• Test Driven Development (writing tests in code before you develop the features) has a wealth of metrics that highlight quality issues early. Establish what these are early on, baseline and monitor throughout the project.

Don’t be afraid to fail or experiment. Learn to fail, and create a culture that learns from failure.

Continuous Planning

It’s a myth that you don’t plan on agile projects. The freedom of agile projects does not come free: you have to plan. You just plan differently and continuously.

Agile planning is based as much as possible on solid, historical data, not speculation. The plan must continuously demonstrate its accuracy: nobody on an agile project will take it for granted that the plan is workable.

Typically teams plan together, usually on at least two levels:

• at the release level, they identify and prioritise the features we must have, and would like to have by the deadline.
• at the iteration level, they plan for the next features to implement, in priority order. If features are too large to be estimated or delivered within a single iteration, they break them down further.

These plans are usually reviewed after every sprint and adjusted based on “the weather yesterday”, new facts and requirements that will inevitably be uncovered along the way.

Bad smells

Teams new to agile should be wary of these familiar situations and reactions to doing things differently. They have a bad smell about them and undermine your project and its chances of success.

• Your team is not full time. If your core team of product manager, scrum master, and key members of your multi-disciplinary team are not on the project full-time and spread over many projects then expect difficulties. The team is the unit of delivery and you need focus. Push back on managers and stakeholders if this is happening.

• You don’t have a dedicated team area. Your team should be sat together, preferably in your own room, with space on the walls to draw ideas and stick up cards and post-its. As the project gets going, consciously ‘hack the environment’ to create a working environment conducive to team working. You might upset a few people and challenge some long-standing working practices. But this is so, so important, and really should not be a big ask.

• There’s no continuous integration environment. Start right: with a continuous development environment. If your teams are not insisting on this from the outset then you’ve probably got the wrong team. So much about iterative software development is contingent on the ability to continuously deploy and run automated tests as you do.

• You have a separate QA department. If your team’s attitude to quality is to throw the software they’ve developed over the wall to a QA department, then they’ve not got the right attitude to delivering production-ready software. You need to embed a quality culture into the team.

This is by no means an exhaustive list, but these are most common things to watch out for.

---

You just finished reading UK Government - What Agile Looks Like! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

I had the honor of doing a keynote talk for the first annual Agile Dev Practices Berlin 2013 on Behavioral Science, NeuroScience, and Psychology [click for keynote slides].

The picture above is what community looks like. The picture above is what spreading love and appreciation for people looks like.

This is why I love our Agile community. This is why I’ll never leave it. #purejoy

---

You just finished reading Pure Joy - What Spreading Love for People Looks Like #agiledevprac! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---

[At Agile Dev Practices Berlin 2013]

Covering the following for Kanban:

• Virginia Satir’s Change Process Model
• Jurgen Appelo’s Fitness Landscape
• Don Reinertsen Queuing Theory

[SEE MY NOTES on Part 1 of Kanban here]

---

You just finished reading @pawelbrodzinski - Part 2 Kanban Workshop - My Notes 2! Consider leaving a comment!

---

We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs.

---