Last 3rd and 4th of December 2014 I attended the CAS 2014 conference that took place in the gorgeous city of Barcelona, Spain. During these two days I attended a series of conferences covering all the aspects of modern approaches on agile technologies along with detailed aspects I wasn’t aware of in project management.
The experience was extremely productive and interesting, and I just regret not being able to attend all of the conferences (normally, you would have to choose between several options, as there are too many speakers at once, and as usual you probably regret attending some, being some kind of lottery somehow). While you can see all the conferences in the official website, most of them were purely in spanish, being not quite convenient for English speakers.
Here’s a résumé of the conferences and keynotes I attended:
Jurgen Appelo Keynote
The main message of his key note was: How can we change our workers? Clearly, by boosting the following key elements: Motivation, organisation culture, manager mind-set, teams that will take responsibility, managers that will trust their teams, and develop people’s competencies.
According to Jurgen, the concept of management is too important to leave it to old-fashioned managers. Everyone is a manager. The world needs less “managers”.
And, indeed, leave the project success to serendipity is not really good idea. Do we really know the people we work with? Do we want to? Knowing each other is an effective way to work, but it doesn’t always work for some people.
When it comes to project completion, there’s a huge gap between the concepts of offering, committed, started, persisted and finished. Only 7% of all the purposes truly make it to the end. The key is to FOCUS ON THE GOOD STUFF. Not in the problems.
After some brief introduction to the concept of Kudo Cards (tokens of appreciation for employees) and the new funny job titles (like “Common senser”!), Jurgen spoke about workshops and performance measurement.
Workshops: are they really useful? You make decisions for others and you may explain your motivation, but a discussion isn’t desired or wanted. Your listeners decide if your motivations are wise. It’s their call. It’s a command.
And when it comes to performance, how do you measure your own? You should always do it by objectives and key results. A good example is the “Runner example”: an optimal result of performance is measurable (let’s say you set yourself a goal of running 10 km in one hour) and should always be 70% or 80% in the best scenario. A 100% score means you’re lazy. It was too easy if you could do everything perfectly. Metrics ecosystems are very good in all cases.
Then we moved to the tricky subject of people’s commitment, something very difficult to achieve. People like fairness over negotiation most times. And when it comes to salary formulas: Commitment should be the measure key, not the hours spent at the office.
In the matter of project failure: failures are part of our daily progress. Without failing there is no learning. A complete success is just efficiency, not learning. Same goes for mistakes.
And finally, a sentence to remember: Scrum is like your mother in law. It doesn’t solve your problems, just points at them.
You can see the whole keynote here. Long but worth it!!.
Unit tests suck and it’s our fault by Jose Armesto
Jose made a very funny but also interesting and productive presentation about how testing code is good for every team if used efficiently and also how it should be coded. Here are some of the issues he pointed out:
Test code is different from other kind of code. There are some subtle differences. Test code must be trustworthy, express the intent and has to be flexible.
It is important to choose good names, there’s no need to read the whole body of the test. Even if the function name is long, the name of the feature should be self-explanatory.
We must also avoid logic inside tests: Conditionals, Loops, etc. Who will test the tests if there is logic inside them? Straightforwardness is the key.
Highlight the important stuff: Do not add much information, just the main points. Think what you can leave out. The name of the feature should be self-explanatory.
Don’t hide the important stuff: express the intent. “Extract method” is not meant to reduce lines of code. Just make it more readable. It’s about thinking, not typing.
The usual suspects in failure are generally setup and data providers. Setup moves important code out of sight. You have to remember where the code was. You lose context on why that code is there. It’s better to use a “explicit setup”. Data providers tend to make tests more complex, the most meaningful parts of the test are outside the test (Input and output).
Builders to the rescue: Building the same objects over and over make everything dependant on the constructor. Sometimes a particular constructor requires variables not needed for the test. It’s a good idea to create a builder in order to instantiate the class.
Create your own abstract language. Create own methods and use them in tests. They can potentially be used in other tests, becoming recursive. They can even make non-developers understand the testing code.
When it comes to describe and execute test doubles:
- Dummy: Substitutes the original but won’t be used. Always use the real objects unless it has side effects or it’s somehow expensive
- Stub: Copy of your class for testing. Value object, Entity and Service.
Avoid test doubles for value objects. Think twice for entities.
Concept of command Query separation principle: Commands change the state of the system but don’t return values. Queries do, but system does not change. This is free of side effects. Stubs are used when you want a query to return a value.
An interesting point was: without test doubles, is it still unit testing? Tests need to be dependency free. Don’t modify tests when refactoring.
How much testing is enough? Write tests until fear is transformed into boredom.
Confidence + Communication = Success.
High code coverage is not a goal, it is a side effect. Most importantly: THINK. Don’t follow rules like these. Just do what works for you, these are just guidelines.
Testing makes you faster. Throw love to your tests. If you go slower, find why. TDD makes things far easier.
Here is the whole conference (spanish).
Scrum Pocket Edition by Vanesa Tejada
Vanesa made a pretty straightforward and simple explanation on the Scrum framework, covering what’s Scrum, the Scrum roles and Scrum cycle. The speech was definitely interesting for newbies. After covering the Scrum master, Product owner, Dev team and Stakeholders roles, she explained the main elements of a Scrum cycle: events & artefacts.
A bit of detail on these events:
The Business meetings make the product backlogs grow: it is the single source of requirements, the product vision. The product owner manages it. The whole team is responsible for it.
The grooming sessions define the details and estimations of the product backlog items. Everyone should be there, including the stakeholders.
The sprint planning defines the backlog and work to be performed by the sprint.
During a sprint, the product owner keeps the backlog clean and prioritized. The stakeholders support requests and progress. The team creates the increment and focuses on achieving the sprint goal. The Scrum master is the leader of the Scrum team, and removes impediments in order to make the development team progress in their tasks.
The daily scrum or daily stand up should cover what we did yesterday, what we do today, and what is blocking us.
The sprint review meeting establishes what’s done and not, and shows a demo of the increment. It decides what we do not need and prioritise next sprint.
The sprint retrospective meeting tells us: How was it? What went well? What can we do better? How do we implement our potential improvements? It’s very important to have a proper look back.
The Main advantages of Scrum:
- Effective team collaboration
- Complex projects
- Iterative, incremental approach
- Deliver products with highest possible value
- Transparency, inspection and adaptation
Here’s the conference (spanish).
Scrum Masters, Product owners, Agile coaches, unicorns and other mythological beings by Isra Alcazar
Israel had a very interesting approach to the Scrum framework that complemented perfectly the previous speech, in a very clever tone, and using a very catchy and straightforward message channelled through the human emotions.
We live in a world of constant tech evolution (Google Wallet, Uber…) and old-fashioned business models need to catch up fast in a world of fierce rivals. Hence, new ways to focus problems have to emerge.
Why Agile now? It’s not new at all. Agile focuses on people, not technology. And also focuses in iteration cycles, cooperation and communication.
Scrum is just a framework with a series of tools and a team or set of teams that must or should be multidisciplinary, small and self-organized.
The product owners are focused in the business model and have the vision of it. They have to be in constant contact with the stakeholders and are in charge of organising and see the best perspective and interests for everyone in the chain. And of course, they need to build and prioritise the backlog requisites. They are the unicorns, like the scrum master.
The Scrum master is the facilitator: shows empathy, listens, removes impediments, coaches and mentors, NOT telling the team what they have to do. The teams must find their own way. Same way the scrum master should be able to help the product owner, being a good speaker and especially a good listener.
The agile coach must be the mirror where the team and roles look at, and the amplifier of issues that some people do not see or appreciate. He must also be a giver of feedback and supporter of the company or organisation in transitions to Agile. Not many so far…
The Team must deliver every 2 or 3 weeks, learn to automatize, testing, handle new responsibilities, communicate, self-organize, having always in mind that not talking is a very bad idea. Sometimes people email each other instead of talking when they’re close to each other!
The product owner must deliver the info, search for new tools in order to know what the users want, be the new speakers, have different responsibilities and abilities, and most importantly being able to say NO in the most assertive way.
The scrum master is the facilitator, the conflict solver, the impediments remover, the promoter of new ways of thinking, the change catalyst. Should a team leader be the scrum master is still a polemic discussion, though!
However, when we talk generally about the people, the human beings that compose the teams, we’re all just a combination of thoughts (facts, body language, values, prejudices, beliefs, expectations), emotions (feelings, fears, Frustrations), needs (what do I need, what do WE need) and actions.
The human thinking moves through belief and emotion into action. For instance, believing the product owner is our boss has consequences. What if I believe internally his ideas or thoughts are worthless or plain shit? We will probably just swallow it.
When it comes to fear, there are many types. The fear of survival (to be fired), to failure (not being totally sure of your efficiency in a particular role, or showing weakness when you’re not meant to), the fear to lose power (Does my status inside the company get compromised?), and change in general. People fear change instead of embracing it and leave our comfort zone.
We cannot forget about hierarchies and the rest of the company. Hierarchies have always existed and it’s something the world has used since… forever?. We must work inside and outside our teams. This makes possible the “invisible relationships”.
Who approves your holidays? He/She is your boss. It’s not healthy who decides this is the product owner. It’s not a healthy relationship. Who you smoke with even if you don’t smoke? It generates empathies and the opposite too. Who you go for lunch with? How can you help each other?
By understanding reality
- Trace an action plan
- Let things be
Conclusion: It’s all about emotions. We just got to learn peoples’ contexts and their emotions so we can help them improve.
Have a look at this fantastic speech here (spanish).
Beyond budgeting by Bjarte Bogsnes
Bjarte made a quite technical speech about self-management and budgeting. While I could not totally connect with this talk (I’m a developer after all), I did understand the value of some of the key points he made:
- Case for changes. What causes the problem that requires a change?
- Beyond budgeting principles
- Statoil model – Ambition to action
Usual budgeting problems:
- Weak link to strategy
- Time consuming
- Decisions made too early and often too high up
- Assumptions quickly outdated
- Accordion forecasting horizon
- Can prevent value adding activities
When managing traffic performance, who manages the information and based on what? We should compare traffic lights to roundabouts: same objective, very different answers. What’s more efficient and more difficult?
Most of management means make people’s work difficult
Self-regulating management is nowadays essential. The world has changed and we must adapt the way we lead and manage, especially processes, to have a balance between dynamic (risky) and stable (rigid, rules-based, centralised, control, secrecy) management. That is the theory X. Theory Y means Values based autonomy, Transparency, Internal motivation. We need to move from narrow measurement into a holistic assessment.
- Translating strategy from ambitions to actions
- Secure flexibility, room to act and perform
- Activate values and leadership principles
Not everything that counts can be counted, not everything that can be counted counts
Here’s the whole keynote (in english!).
Generating tests by Rafa de Castro
Rafa made a pretty fast-paced but extremely interesting speech about tests generation, focusing in impediments and key points to follow if we want to have efficient test suites for any purpose.
Why do we have a complicated relationship with TDD? We love it until we have a production bug or something does not work as we expected. We can test properties by using tools such as Scalacheck, Rantly or test.check, but Rantly was chosen as the tool to use during his talk.
First step: have generators such as string, integer, list, hash…
Shrinking goes next, reducing the string or data to see if the test passes. That way we know “reduced successes” and the minimal failed data. Shrinking is extremely important, as it allows developers to THINK.
Finally, some good practices when it comes to tests generation:
- Create a command pattern: a common interface with all the possible commands for our system.
- Aim for concurrency, possible but difficult to achieve. A unit test by definition must be repeatable. But it’s awfully complicated.
- Create a sequential phase and a parallel phase with threads.
- Refactor with less fear!
Finally, he recommended reading the book Scalacheck: the definitive guide.
Have a look at the conference (spanish).
Integrating UX & Design in Agile design / The history of the after years by Antonio de la Torre
Probably one of the best conferences I attended. I really fell in love with the contents of this speech and the passion Antonio put in it. The slides were also great! Here are the key points:
Two years ago we would create user stories from the info given by the manager, a maybe not very useful practice. A new way to work was needed. How could we work this out? By using mixed teams we would get fewer storms, a new way to work with everyone’s needs.
The design part seemed to be isolated always from the Agile project, as if it was less important. The level of empathy with the UX team meant lots of discussions.
The list of functionalities is pretty much defined by the UX specialist. They know what the user needs. They help defining the product by creating the MVP (Minimum Viable Product) and the iterations. They facilitate team dynamics, inceptions, user personas, workflows and Things that matter and not. Most importantly: they provide empathy.
The main point: The analyst as we know is DEAD.
The agency model: cascade with Analysis, UX, Design, front and back end development… analysis means knowledge. The design part means rework, contract extensions, parts that were ambiguous… and this is why there are so many contracts in the market.
As a good practice, there should always be a two-hour meeting with designers in order to save a lot in misunderstanding. It’s called Lean UX.
How does this work for Scrum and the sprints?
UX plans activities shortly before scrums by defining stories, wireframes, prototypes, etc… but how shortly before? Just enough to set the definition of “ready” and assist the sprint definitions of the project to be validated by the customer.
Everything goes together. Designing all stories at once doesn’t make any sense. It’s not the same the story of the landing page than the story of the user profile. The backlog needs to be defined in parallel having the designs into account.
Working with “The tool”: We want everything in “The tool”. In the sprint kitchen, sprints are not reutilisable. But there should be sprints for design, and designs for other issues? Reordering is essential in order to block and prevent further suffering. Other way to do things is divide tasks in two, but this is not a good practice.
Cooperation is the key! Focus on Sprints! Work! Be productive! Then usually two weeks later we decide to pay attention to other projects. WTF?? This is so bad for motivation…
You can’t fill Sprints with execution. It is about Knowledge. It is about quality. This is the approach of a designer. The designer knows the product deeply, same with users.
Definition of a Kanban flow (LINK): Improve the flow, less planning, more collaboration, iteration and reduction of waste. With it, the organization of Sprints disappears, but still needs a high responsibility in pulling from it. It needs dedication as well: to know who needs to do what at all times. Kanban means “pull”, but the main focus of Kanban is to dramatically reduce waste. All that’s started is finished.
And then what? The team should keep on growing with designers and UX engineers.
Feel the force and trust your Scrum master (or Agile hero you have inside).
Here’s the full conference (spanish).
Software debt by Angel Núñez
While the subject is one of the most interesting ones when learning the Scrum culture, this speech felt literally taken from one of my favourite Scrum books, Essential Scrum. Most of the slides came from this very book and I definitely encourage you to read it.
The cases explained during this speech were practical ones where release dates haven’t been achieved, real cases: problems with Drupal, one of the most used CMS in the world.
Technical debt was detected in their platform at some point and that’s what was killing Drupal. They couldn’t handle the technical debt.
Technical debt slows development, but can be repaid. The problem happens when this debt is not repaid: it grows exponentially and every minute spent in not-quite-right code counts on interest on that debt.
Technical debt is like drug addiction. Once you hardcode, the code wants more. The technical debt is not totally bad as it can speed up development as long as it is quickly repaid. It is also okay for quick deliveries; reduces initial costs or sensitive delivery dates.
Software tech debt is inevitable. Its problem is not its existence, it’s its management. Problem isn’t just the developer, the code or the refactor. There are many kinds of software debt: Technical, Quality, Design, Infrastructure, Configuration management…
The holistic management means: involve and educate, visualise and measure, sustain, attend and pay, plan and experiment…
Involve and educate the product owner. He’s the first to be involved. Evaluate the software debt impact. Visualise and measure by code metrics, velocity and bugs. Sustain rhythm and quality: Don’t push, but pull.
Here’s, once again, the full conference (in spanish)
BONUS TRACK: Round table with Cristobal Colón, Pedro Serrahima and Jorge Uriarte regarding work ethics.
Unfortunately this fantastic video is only in spanish, but if you have the chance to see it (and understand it!) or subtitle it, please do it. It’s a really inspiring and beautiful insight on the beauty of work and ethics above economical interests.