TampereGoesAgile 2011

Tampere Goes Agile 2011 17.9.2011

Agenda for Tampere Goes Agile is found here

Follow event on Twitter: #tamperegoesagile or use this direct link

On the road at #tamperegoesagile by Henrik Taubert (@htaubert),  Kjell Lauren (@klauren69) and Kaisa Kettunen (@krkettunen)

The Role of Management in a Agile Through Real Life Stories by Ari Tanninen

– Case1: Zynga
Team formed with missing pre-knowledge on 2/3 of the needed competence areas
–> Consider competences when forming teams and listen to the teams, reserve time to be there!
What is the role of management in this case ?
No management in place…
Management was busy keeping everyone busy => Not the way to go!

– Case2: Testers
What is the role of team members?
Uneven background on Agile WoW within the team caused bad progress and atmosphere
* Old-fashioned testers holding development back
* When removed, velocity of the remaining team doubled
* Remaining developers had gone through the learning curve and had the testing skills
* The testers went to other teams (peer coaching time/effort available)
–> Keep experience in majority compared to newbies in teams
Developers and testers separated within team
Developers agile, testers sticking to their old roles
Huge gap in knowledge between developers and testers

– Case3: Figure It Out!
Upon Agile transformation, productivity of previously effective team dropped due to “Figure out how to …” stories from PO
* Endless spike activities to “Figure it out” by the team
* When PO changed, velocity rocketed
–> Choose the right guys for the right job and make sure they understand the expectations
PO lost
80% of teams time went to figure out what they were supposed to do
Don’t be afraid of changing people in team if things are not working.

– Case4: Star organization
Customer (=money) not visible to the subcontractor
* Subcontractor team delivering to a “product team” (without clear understanding of their needs)
* Product team’s work depending on “platform team”, which not supporting them
* “Support team” serving too many (15) client teams – overloaded
–> Assure right structures, e.g. keep customer close (e.g. subcontractors) or usage of right methods (e.g. Kanban) for right setups

– Case5: Silo
Consultant team writing SW for managing “Factory -> Logistics -> Customer” chain
* Multiple proposals which do not support business process
* Despite of no value produced, the project continued due to the made agreements…
–> Don’t be afraid to make/take the decisions despite of going Agile

The Practicing Programmer by Johannes Brodwall

– Practicing Programming – how to work and learn better
– Session starting off with pair programming TDD Minesweeper demo…
– Showing incremental TDD mindset with a pairProgramming twist.
– Simple case, but shows the practice really well. The challenge would be to scale to more complex environment. TDD forces better structured code, improved maintainability.
– sidenote: interesting to see the concentrated looks on the faces in the audience. 🙂 Geeks or what?
– Maybe a lenghty demo is not the best format for a conference “presentation”, but the basic idea is good. Highlights the communication aspect of pair programming, refactoring and TDD.
– Ping-pong programming, switch when tests fail….
– Demo showed many aspects of TDD and pair programming, continuous refactoring, both on tests and production code, tool usage learning.
– Use eg helper methods for tests in order to minimize the impact of changing the interface of a class
– Make use of the abilities of the IDE and editor.
– Why Become a better programmer…
– focus on problem instead of language
– harder problems become easier

– Pair programming practices, and drawing a “pairing net” for the team. Question at the end of the week, “why didn’t you pair up with more people?”
– all in all a rather good session, but a bit poor time management.

The (Hitch)hikers’ guide to Agile Leadership by Aki Salmi

– Aspects of hiking
* project lifecycle (locate -> observe_plan_do_?)
* continuous learning
* leadership
* safety comes from hard + soft skills + common sense

– Expectations: all unique/different with different expectations
–> Maintain a personal touch, care, use your insticts and live your dreams

– Hiking story (where everything goes wrong, is difficult and frustrating):
What enables you to lead and go forward?
* Learn and get experience
* Work with reliable people
* Don’t panic
When physical safety is jeopardized and psychological safety dangered, social safety takes you a long way

– Tips for hiking and leading:
* Take the time to socialize
* Morning coffee (an easy start for a day, ‘do food’, I value us all)
* Communicate your plan
* Formation matters
* Appreciate silence
* Walk side-by-side: Be always present, but not always “on stage”
* Interactions among group: Feeling of being valued/cared
* Be trustworthy
* Value us all: as a team, we can make it
* Learn together: ask help from the others
* Feeling safe, feeling free
* Beaty in our surroundings
* Enjoy the life as it is
* Share the pain of the rough terrain
* Share the success

– Leading on personal level:
– Take care of yourself
– Take your own time
– Have a friend there for you
– Enjoy, seize the moment
– Have fun!
– It might be tough at time
– But at the end, there is success
–  It’s always about the people!

Interesting analogy between hiking and work! Surprisingly similar things apply for both!

What Every Agile Developer Can Learn Form Startups by Oleg Podsechin

– What drives managers vs developers?
– customers? driven by value for money…
– SW devel is like a constant experiment, you never really know where you end up.
– SW devel as extreme sport
– sw devel as “being frankenstein” sometimes you end up creating monsters
– How do projects get started:
– someone thinks they know what ppl want; raise->build->sell->fail
– instead sell->raise->build
Startup: be lazy; learn from other’s mistakes, don’t re-invent the wheel
– The customer is not always right, nor know what they really want. Customer centric approach is somewhat risky.
– too much customer collaboration result in bloat.
– don’t build for just one customer; how does the soolution scale, fit in the market?
– SW projects are not like plumbing, more like long term relationships – being married… or worse…
– build mutual trust on all levels; devs are not just resources, and the customer is not just a source of revenue.
– Optimize the team(s)
– avoid overhead
– XF teams are good, small teams of specialized generalists are better
– Hire the right people; great instead of mediocre (rockstars and nijas who are nice persons) Expert without ego problem 🙂

– Managing expectations
– how to handle them when reqs change often
– new reqs mean more work
– key tools; burn-up and bur-down chart to visualize issues for customers as well
– Milestones; -needed formeasuring progress, invoicing, and a way to be able to celebrate achievements.
– “if you’re not embarrassed by the first version of your product, you’ve launched too late…” –LinkedIn

-importance of prototyping; Functional prototypes are good for showing ideas and big picture
– Gives the customer an idea of what they’re getting
– good base for a contract
– charging for a proto is good way to validate your customer…

– Not everyting can be descrie as a feature
– all features don’t need to be shipped
– Modularity is good; (re)usability, maintainablity..
– Why not open source your work?
– promoting your work, recruiting tool, aids motivation

– Failure is good
– learn from it
– know when to quit

– distributed teams….
– the future,
– Tools shall help, rather than hinder
– use the same tool everywhere for communication, follow-up

Software Craftsman – Passionate and Pragmatic Chameleon by Jussi Mononen

– Software Craftmanship manifesto

Ethics:
– Do no harm
– Honesty. Is capable and adept at saying No!
– But wants to say yes!
– Estimation
Humility
– We must be humble (in a correct way)
– We are not infallible, but aim to be
– We build on the shoulders of giants
– Admit and learn from you mistakes
– Review thyself!
Care
– It is our responsibility to gain trust from the business
– We put our reputation stake everyday
– Quality, robustness, maintainable…
– We are not just “programmers”
Community
– Share
– Mentor
– Help
– Take part and engage
Passion
– Fuel
– Do everything at 110%, even if you don’t like it
Participate
– Don’t wait to be told, ask!
– Learn the business
We practice
– Really. Craftsmen practice!
Apprentice
– Practices
Journeyman
– Practices
Master
– Practices
When
– Craftsman practices on his own time, because we cannot rely on charity time. We perform at work.
Widen the horizon
– Learn
– Curious
– Step outside the box to see it
– Orthogonality
Know it all
– Generalists
– Generalists are curious, specialists are incurious
Specialists
– We still need to know enough
– ..but we don’t lock ourselves in silos
Pragmatism
– Tooling & Technology
– Sustainable pace
– Zero heroes
– Context
Ensure quality
– Tests
– Automates
– Does not compromise quality. Ever.
Chameleon
– At home in every situation
– Legacy. Green/Brownfield. Maintenance. Emergencies.
Are you worth it?
– Salary? You cost more.
– How much value did you produce last year?
– Are you a worthy investment?

Craftsman is a worthy investment
I want to become one, do You ?

– Community: Share, mentor, help, take part & encage
– Passion: 110%
– Participate: Don’t wait to be told, ask! Learn the business.
– Practice, practice, practice – despite of your level you can always improve
– “Craftsman pracices in his own time, because we can not rely on charity time. We perform at work.”
– Widen the horizon: Learn. Be curious. Step outside the box to see it. Orthogonality.
– Knowitall: Generalists are curious, specialists are incurious. Don’t lock yourself into silo.
– Pragmatism: Tooling & technology. Sustainable pace. Zero heroes. Context.
– Ensure quality: Tests. Automates. Craftsman does not compromize quality – ever.
– Chameleon: At home in every situation. Legacy. Green/brownfield.
– Are you worth it? Salary – you cost more… Would you invest in yourself?
–> “Craftsman is a worthy investment”

Agile in Big Corp – How to Survive by Kirsi Korhonen

– Accepting the top-down agile – Bottom-up Agile is accepted
* Organizational practices (e.g. backlog, sprint cycle)
* Team practices (e.g. dailies, retros)
* Programming practices (e.g. TDD, pair-programming)
–> Explore Agile within certain boundaries, which become less and less the more detailed you go
–> “Choose the “games” (practices) you want to play, and play them the right way”
–> Work with the culture to elevate the change
– I don”t know what the others are doing in my team
– Playing the right games the right way.
– What is good for you and the team, one size does not fit all

– Challenges in the teams
* Developer teams:
* Collective code ownership? (8%)
* Insufficicent specs, reqs and USes (17%)
* Big plan?
* Verification teams:
* More meetings than before (28%)
* Agile testing procedures? (25%)

– Fast feedback in integration important
* Faults are ok as long as you detect and fix them fast
* Example #1: Nr faults found in Waterfall vs Agile (6 & 12 months experience)
* Number of defects overall lower
* Defect numbers stabilized for final verification round
* Example #2: Despite of good testing/quality during sprints, peak in faults in final testing phase it then stabilized

– Commit, Commit, Commit
– It is not done before it is tested
– Don’t forget to check your end-to-end functionality in a big system
– Fixing the faults with wisdom
– Knowing the priorities – and respecting them
– Group work rules!
–> Faster to-the-target communication
– Keeping promises
* Learn e.g. planning poker for how to do the planning/estimations
* Identify what is needed to make the plan happen
– Knowing the problem you try to solve
– I don’t see any value in the retrospective! We always find the same problems and nothing happens.
– What does it mean to have retrospectives? We want improvement! What other ways are there to improve?
– Agile is for software developers! I don’t understand how it can be applied to my work as I am not programming any code!

– THE Key: Know what problem you want to solve and then decide which methods/tools/practices you want to use to solve it
* Example: Problem with retrospectives -> find the key issue to address and work forward from that

– “The point is not changing the organization culture, but to understand and work with it, to build on strengths”

– How do you survive?
* Collect the reasons why you should take a practice in use and what there is to gain?
* How do you (and others) know that your problem is gone when adopting Agile practices?

Agile Browser: http://wiki.meego.com/AgileBrowser

‘I Read the Book, Why Doesn’t Work?’ by Stanislav Vasilyev

– Books with different purposes…
– Book as instant feedback.
– comparing development practices to Vacuum cleaners… right tool for the right purpose
– one practice does not fit all environment, either adapt the tool, or take another, more fitting tool.
– Unconcentrated speech.. and mostly off the actual topic.
– a gadget doesn’t change the org, it’s the operators, the people that do that.
– SW devel make it easier to spread the tooling than construction.
– The product reflects the org, with all its benefits and problems.
– You get what you ask for, what you measure, since people tend to take shortcuts, the easy way out
– what will wasteless SW development end up in?
– The cycle of respect…
– know you people, who and what they are?
– know when to trust and the team and how to trust them…
– With SW devel you don’t always have anything really tangiable
– share the achievements but celebrate also failures.

– the essence of the talk as a blog post: http://stanvasilyev.blogspot.com

Maneuver Warfare and Other Badass Habits of a Lean Product Developer by Marko Taipale

– The 2 reasons:
* We are investing a lot of time & money to do the wrong things
* 53% don’t know what the company is trying to achieve
–> Purpose of the work unclear, non-existing or not communicated

– Lean product developer:
* Respects people
* Understands, establishes and clarifies the purpose
* Improves continuously by learning

– How to become a lean product developer? The lean steps:

“Lean” your business ideas
– What is a “business idea”?
-> It is just a “series of guesses”
– How to communicate you business idea?
– How to validate the guesses?
-> business model canvas -> validate with customer development (=get out there)

Build faster (or not at all)
– Make an inventory of and shorten the Business idea->Deployment time (e.g. continuous integration, continous deployment)
–> Think big, implement small
– Think timing (Just-In-Time)

Measure it!
– What are the things we NEED to measure?
– Levels of monitoring (business->application->etc)
– Funnel analysis
– Measure what matter to you
– Measure to throw away the waste (optimize the whole system)

Learn fast
– Go out, keep in contact with customers
– A way of learning: 5 whys
– A3 template for problem solving <– Google it!
– Truth is out there: Ship it & get out from the building

Identify root causes and use A3 for problem solving
A3 template for problem solving (google search A3 problem solving)

– And don’t forget: “Customers are a part of the system”

Patterns of Agile Adoption by Vasco Duarte

– Patterns as projections of real world
* Compare: Plato’s world concept (i.e. world of ‘shadows’ which we can not see)
* Symptoms of useful/not so usefull factors/actions during transition phase
– In a waterfall project you have a big pattern called THE Plan
– In a linear-iterative development you might do some coding or prototyping
– In agile development you do what it takes to trace a bullet through the system
– In early architectures, “trace a bullet” through the whole sw stack: implement something _E2E_ to learn about the stack.
– building communication is very expensive, get to it early
– communication can’t be forced, is must be grown and supported. Focus on supporting the positive patterns…
– No matter whether you do scrum or kanban, you are anyway doing it wrong, but don’t worry
– You should not have a code freeze or code complete date in agile. The value you deliver matters!

– Self-awareness and Reflection
– The Agile Project Score Sheet for you project http://bit.ly/agileScoreSheet

– Waterfall/Linear iterative (e.g. RUP)/Agile comparison in project life-cycle (start – middle – end) and anti-patterns
Start:
* Waterfall: Detailed time/task planning of everything
* Linear: Iterative detailed time/task planning
* Agile: Slicing with tracer bullet
Middle:
* Waterfall: Burnouts from constant overload
* Linear: Integration camps upon merging after an increment
* Agile: Complex interworking/-action without barriers evolving autonomously
End:
* Waterfall: Project prolonged due to bugs collected and fixed at the end
* Linear: The “landing” curve, i.e. when to statistical to reach 0 bugs
* Agile: No code freeze exists/code complete, focus on value
No one single way of doing Waterfall/Iterations/Agile
–> For Agile, choose which patters you want to amplify and which ones to damp