Category Archives: Teams

What makes you Fit for Purpose?

Can someone answer this question?   Well yes, I can help.  In short it’s what you do, be that individually but mostly in a team, to ensure anyone you serve receives the service you provide in a reasonable time frame with appropriate quality.

Where does that start?

It starts with understanding who your customer is.   Taking steps to learn about the customer and what satisfies them.  There are some tools available to you to help like Customer Surveys, Customer Interviews, Customer Empathy Maps, Personas and going to see for yourself.

Somewhat lagging but still providing information about the customer and their needs ( which can and are probably changing) is a Net Fitness Score which is an alternative to Net Promoter Score.  If you are producing software you can add code to capture data about how your customers are using the application.  This is is part of a process called instrumentation that is done to computer programs.

This takes us into the area of measurement.  In addition to customer measures, a team can also use other metrics to ensure delivery is just right.  By just right, we mean that any feelings of over-burdening (muri) are minimised to ensure that a team can sustainably deliver work.

Here some measures include, service response times (cycle time) for the different types of requests a team gets.  Are we able to deliver those reliably.  By reliable we mean within the realms of probability and not exact measures.  Knowledge Work being naturally variable in nature we tend to defer to probabilities like a Service Level Agreement. 85% of the time we can deliver in 3 days as an example.

In aiming for better on-time delivery you may need to eliminate muda or wasteful activities.  You may find amplifying collaborative activities and learning new skills will help. These type of improvements stem from understanding the nature of different requests like demand (high and low periods), expectations of quality and when request are expected to be fulfilled (Cost of Delay).

Another measure is acceptable defect levels, with the aim to reduce these to a negligible level.  Defects may need to be balanced with responsiveness.  If you require greater responsiveness then Fit for Purpose may mean acceptance of higher failure load (another name for total defects).  Responsiveness may also mean less predictability and some work may have an have a wider range of delivery date performance.

If failure load is high, then addressing some level of quality can also have a bearing on on-time delivery.  In software development that means ensuring little or no technical debt.  High levels of technical debt lengthen cycle times as a team looks to deal with the complexity of software laden with technical debt.   Continually reducing and maintaining low levels of technical debt will help maintain reliable delivery.  It will also allow innovation to occur because the team is freed from the burden of low quality.

Addressing these and becoming reliable means you will have confidence to communicate service level expectations within reasonable levels of probability.  Doing this with appropriate quality will often result in plaudits to the team and reversing what may be many sources of dis-satisfaction for the customer and team a like.  Find out what makes your system of work Fit for Purpose.  Work hard on reaching that level.  Agility will be a natural result.


Agile before it was cool

This is a page from a great book by an important author in the software development field, Tim Gilb, called Principles Of Software Engineering Management.  It came out in 1988.

20160119_202722

The language is reminiscent of the time and the practices that were in place then, but it was ground breaking in that it talks a lot about what we call Agile Values today.  In fact Tom Gilb invented his ‘Agile’ and ‘Iterative’ EVO methodology in the early 1970s.  It’s mentioned in the book as well.  This was well before Agile became what it is today – a business.   Tom was so ahead of his time, I remember back then that Iterative development was never ever mentioned in schools and in the workplace.

And therefore, I think this Bill of Rights still holds relevancy.  I made the challenge on twitter and some thought point 9 was not relevant, rather a relic of the past.  I tend to think it’s misinterpreted in the twitter response.  Here’s the link to the twitter feed and a snap shot below.

 

There is power in this for the worker here, even on performance.  Leaders can use this to create an ethos of transparency.  Looking back to look forward.


Where’s the teamwork when we can’t see each other

I’m an Australian working in the USA coaching highly distributed teams. We speak English but even then there are slight differences, like Australian English and American English and even within America like from South to North.

We find it’s hard to get people to use video cameras. They are cheap however the culture tends to not encourage use of them. It’s always hard to collaborate at the best of times and distribution would be a good excuse not to do that.

Seems most distributed companies can’t get past just the phone and a little screen sharing.  When we use just these, we can’t see each other’s facial expressions and body language.  It’s hard to know how to react to feelings and we have to assume or turn up our intonation sense when listening (perhaps even speakers and listeners can make more us of their voice to relay feelings).  Another big issue is having attention – where I work inattention is called ‘multi-tasking’ and we know that don’t work.

Overall, this is more a problem around the difficulties in collaborating and the fears around that.  We’ll need to work on that to allow the tools to be useful.  Make it safe.  Create the culture and camaraderie of teamwork and reward that.  Highlight even when people are doing things that harm teamwork via a team working agreement.  Realization can quickly occur after that and a team can self correct.

Then there is technology, my friend Agile Bill Krebs, is teaching and coaching on tools to assist the distributed work place.  There are simple tools like join.me which is down the low end of the spectrum through to immersive environments like Minecraft.

The technology is there – it just needs a willingness to try using it and adapting to use it to it’s utmost advantage.

Your last resort is to abandon the distributed model.  That can be avoided I suggest.

 


Put the Analyst into Analyst/Programmer

I used to say for over 15 years, put the Analyst back into Analyst/Programmer. This was when many jobs where advertised as Analyst/Programmer, but the Programmer never really did any meaningful analysis. It was mainly confined to the act of writing code not so much about the understanding of requirements.

The reason it fell into disuse is probably correct when you look at the traditional ways software was produced.  Another reason could be the cognitive load required between swapping out of coding and understanding requirements. This a more like an excuse rather than looking for causes.

I’ve now come to say put the Analyst into Analyst/Programmer.  It was never really there in the first place.  A programmer can and should have valued input from the beginning of the software production process.  That does also mean being a nice person and maybe strengthening into areas not so familiar like talking to customers – it’s a communication process as much as a technical process 😉

Inspired by this talk from Martin Fowler this year that I feel aligns with this ideal, I’ve included the following call to arms that I now start my Agile Programming course with, which is to be released soon.  I hope to sharpen it up a bit more.  You can have input into it if you like.  Here’s a start:

As programmers we are more than just code monkeys​. We are motivated to create value for our customer​, so we should be on board with everything including:​

  • Being able to speak to our customers to learn the domain we are working in​
  • Being able to seek clarification from anyone​ be it Business Analysts, Customers, Product Owners, Testers or anyone else
  • To question anything that we have concerns about​
  • Expect to have a meaningful input into understanding requirements​
  • Expect to inject innovation and have it considered

Over to you.  Admittedly there is some work to do to unravel decades of silo based work practices.


Agile and Lean Bookshelf

Some books on lean and agile software development.  The list is still in development.  I’ve read all of these books and will not place books here that I have not read. Some books resonate more than others, but still don’t expect instant recall of all the detail – rather the key ideas and concepts and then drive into the detail if required.

You’ll find some books are relevant to more than one section, so they will be repeated in the sections in which they have relevance.

The Lean and Lean Startup Side

Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated  The archetype Lean book for the Western Reader from leaders in the field. Real life case studies of people over process.
This is Lean: Resolving the Efficiency Paradox
Running Lean: Iterate from Plan A to a Plan That Works (Lean Series)
Kanban: Successful Evolutionary Change for Your Technology Business  Start with this for Kanban, let it sink in, read others and then come back to this.
Leading Lean Software Development: Results Are not the Point
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
The Goal: A Process of Ongoing Improvement
Kanban in Action  I nice start for those wanting to learn about Kanban, don’t ignore David Anderson’s book though!
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win  Systems Thinking for IT People.  Be nice to those Brent’s they only work in a system.
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Personal Kanban: Mapping Work | Navigating Life
Lean-Agile Software Development: Achieving Enterprise Agility
Lean Software Development: An Agile Toolkit
Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale

The Agile and Lean Frameworks Side

Essential Scrum: A Practical Guide to the Most Popular Agile Process (Addison-Wesley Signature Series (Cohn))
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley Signature Series (Cohn))
Kanban: Successful Evolutionary Change for Your Technology Business
Scrumban – Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Lean)
The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)
Real-World Kanban: Do Less, Accomplish More with Lean Thinking
Agile Project Management: Creating Innovative Products (2nd Edition)
Agile Software Development with Scrum (Series in Agile Software Development)
Kanban in Action
Agile Project Management with Kanban (Developer Best Practices)
Agile Project Management with Scrum (Developer Best Practices)
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
Lean Software Development: An Agile Toolkit
Succeeding with Agile: Software Development Using Scrum
The Art of Agile Development
Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press)
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)
Scaling Software Agility: Best Practices for Large Enterprises
The Software Project Manager’s Bridge to Agility
Scrum and XP from the Trenches (Enterprise Software Development)
Actionable Agile Metrics for Predictability: An Introduction

The Technical Side

Domain-Driven Design: Tackling Complexity in the Heart of Software
Pair Programming Illuminated
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Agile Testing: A Practical Guide for Testers and Agile Teams
The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)
Clean Code: A Handbook of Agile Software Craftsmanship
Code Complete: A Practical Handbook of Software Construction, Second Edition
The Pragmatic Programmer: From Journeyman to Master
Growing Object-Oriented Software, Guided by Tests
Agile Software Development, Principles, Patterns, and Practices
Patterns of Enterprise Application Architecture
Refactoring: Improving the Design of Existing Code
Refactoring to Patterns
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
Continuous Integration: Improving Software Quality and Reducing Risk
Test Driven Development: By Example
Pattern-Oriented Software Architecture Volume 1: A System of Patterns
Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
Design Patterns: Elements of Reusable Object-Oriented Software
Extreme Programming Applied: Playing to Win
Writing Solid Code (20th Anniversary 2nd Edition)
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
Working Effectively with Legacy Code
Dependency Injection in .NET
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The Product Ownership and Agile Requirements Side

User Story Mapping
Scrum Product Ownership: Balancing Value from the Inside Out
Working Effectively with Legacy Code
User Stories Applied: For Agile Software Development
Agile Estimating and Planning
Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn))
Impact Mapping: Making a Big Impact with Software Products and Projects
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
The Principles of Product Development Flow: Second Generation Lean Product Development

The Agile Tester Side

Agile Testing: A Practical Guide for Testers and Agile Teams
More Agile Testing: Learning Journeys for the Whole Team
The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)
Testing for Continuous Delivery with Visual Studio 2012 (Microsoft patterns & practices)
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (Net Objectives Lean-Agile Series)
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
xUnit Test Patterns: Refactoring Test Code
Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The People Side

The Five Dysfunctions of a Team: A Leadership Fable
The Introvert Advantage: How to Thrive in an Extrovert World
Emotional Intelligence: Why It Can Matter More Than IQ
Fearless Change: Patterns for Introducing New Ideas
Turn the Ship Around!: A True Story of Turning Followers into Leaders
Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))
Peopleware: Productive Projects and Teams (3rd Edition)
Drive: The Surprising Truth About What Motivates Us
Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency
Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
Death March (2nd Edition)
Agile Retrospectives: Making Good Teams Great
Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision
The Core Protocols: A Guide to Greatness
Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers
Dynamics of Software Development
Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Project Retrospectives: A Handbook for Team Reviews
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
Who Moved My Cheese?: An Amazing Way to Deal with Change in Your Work and in Your Life
The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
Liftoff: Launching Agile Teams & Projects
The Fifth Discipline: The Art & Practice of The Learning Organization
Switch: How to Change Things When Change Is Hard
Start with Why: How Great Leaders Inspire Everyone to Take Action
Team of Teams: New Rules of Engagement for a Complex World
Principles Of Software Engineering Management
Emotional Intelligence 2.0
How to Win Friends & Influence People
Smart Questions: The Essential Strategy for Successful Managers
Great Boss Dead Boss Recommended by David Anderson in KCP Training. A model of identity.
Lessons in Agile Management: On the Road to Kanban
Thinking, Fast and Slow Science on how parts of the brain work. Involuntary vs Logical parts
Nonviolent Communication: A Language of Life, 3rd Edition: Life-Changing Tools for Healthy Relationships (Nonviolent Communication Guides) Judging or helping? Which is more helpful?

 The Organisational Side

Reinventing Organizations
Team of Teams: New Rules of Engagement for a Complex World
Maverick: The Success Story Behind the World’s Most Unusual Workplace
The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer
Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results
Why Plans Fail: Why Business Decision Making is More than Just Business (MemeMachine) (Volume 1)

 The Coaching Side

the act of coaching is distinct from the People and Organisational Sides although strongly linked

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) It’s a start but it won’t be enough
Executive Coaching with Backbone and Heart: A Systems Approach to Engaging Leaders with Their Challenges For real meat on the act of coaching. Years of experience here
Co-Active Coaching: Changing Business, Transforming Lives More meat on the idea that people have the ability to solve/change/improve their lives. Partnership wit a coach
The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever A good start, go to other sources still for more detail
A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas Build that muscle of inquiry first before jumping to a solution

Ideas on How to Give Feedback

feedbackwelcome1-424x218

In a previous article I suggested to not immediately jump to conclusions and be curious about what someone is saying.  It’s something in the realm of Focused and Global Listening that is mentioned by Agile Coach Lyssa Adkins here and in her book Coaching Agile Teams.

It takes some intuition to not sound patronizing as well.   It’s important to be genuine when delivering feedback and not stilted in any way.  Anything that sounds non-genuine will be noticed immediately and most likely visible through body language of the recipient.

You should feel this as well as the deliverer – when you do feel it make a note to conduct a mini-retrospective on your self or with a colleague to try and improve on delivery – especially if you feel it occurring often.

Toastmasters provide a framework for giving feedback, which I’ve adapted, is as follows:

  1. Ask yourself how you’d like to receive feedback.  Private feedback is appreciated.  Find something they’ve done well as a starting point
  2. Ask!  Understanding where they are coming from can help your focus your feedback
  3. Leave out negative words ‘Never’ and ‘Always’.  Your opinion is one of many.  Limit yourself to the problem at hand and use specific examples and be concise.
  4. Focus on the Performance not the Performer. Remain objective.  Demonstrates confidence that they can do it
  5. Keep it Motivational.  Use the sandwich – Commendation, Recommendation, Commendation. Substitute ‘You did it wrong’ with ‘I know a way to get great results’  Deliver in a friendly tone and smile.  Helping them helps everyone reach their goals.

Have a look using your favourite search engine – you can find videos from Toastmasters about giving feedback.  I found them useful 🙂

Please share your own ideas on giving feedback.  I’m not an expert on anything 🙂


acQuire Technology Solutions releases the 2014 version of their fantastic Q Book

Earlier this year I interviewed Tadhg McCarthy about a company he helps manage called ADAPT By Design.  ADAPT By Design is a child of acQuire Technology Solutions and today they released the new version of there fantastic Q Book.

This is a great example of allowing success to occur to everyone.  It must be a great place to work, and work should be fun as well as productive – the two are intimately linked.