Management 3.0 exercises: Delegation Poker & Meddlers
Two important areas of agile management are empowering teams and growing structure. Teams are complex systems working in complex environments. To adapt fully in their environments teams must be able to self-organize. Yet managers need to guide teams so that they produce value in the organization and act according to the organizations goals. Combining self-organization with managerial guidance is the main theme of Delegation Poker.
Many teams operate within the context of a complex organization, and that it is important to consider the form of the social network through which communication flows. In Meddlers, the players discuss and explore different options of structure for larger scale development organizations.
Scrum master as team coach
It is often said the ScrumMaster is a team coach, committed on the continuous improvement of the team. But… what the *** does this mean? What resources does such a ScrumMaster need to perform in the role and how can these be learned? In this interactive presentation I will show some useful techniques that ScrumMasters can apply in their daily work to support your self-organising team. The audience will also be invited to share their experiences and a few case studies will be shown. The presentation is also useful for product owners who want new ways of working with their team - they're servant leaders as well, after all - and, in general, is recommended for everybody who is interested in learning new ways to interact with people.
Using personas in service design - continuously
Personas are widely used to describe the vital end users. Usually designers are working close with client to give the end user a human factor. Personas evolve during end user interviews, workshops and so on. Using personas is chic. Let's make it a chic tool to really use. So... how to make sure the end user is in our focus during the whole web development? From the very first sketch to the 1st and to the 10th release? How to make personas visible for the whole project team and how to update and evolve the personas continuously? To be honest... this is the problem I have been working with for a while. Found some right answers and best practices. Come to the workshop and find the ultimate enlightenmentwith me!
Kanban Pizza Game
For IT professionals who want to pick up Kanban, the agile42 Kanban Pizza Game is a unique and fun learning experience that lets you create and improve a Kanban board in a risk-free environment.
Unlike all other Lean and Kanban games we have seen, the Pizza Game is not based a fixed Kanban board and a pre-defined value stream. Instead the Pizza Game covers the creation of a new Kanban board from an emerging process and allows you to modify the board freely, which closely mirrors what a new Kanban team needs to do early in the transition process.
Do you like pizza? Are you interested in Kanban? If so, there's no excuse for skipping this game! (Max. 24 participants.)
Why do we estimate? What are the benefits we want to obtain with that practice? In this talk we'll explore the nature of estimates and offer an alternative: #NoEstimates. We'll look at some examples of how we can predict a release date of a project without any estimates, only relying on easily available data. Finally, we'll see how we can follow progress on a project at all times without having to rely on guesswork, and we will review how large, very large as well as small projects have already benefited from this in the past. At the end of the session you will be ready to start your own #NoEstimates journey, the next step in the #Agile journey.
If you know how the weaknesses of a system, you will be better at protecting it. Taking a system hacker's perspective will help you do just that. I will present examples from my own consulting practice and give recipes for both disaster and rescue.
Agile Release Planning
In this session, you will be the Product Owner. You need to release a product version after 7 Sprints. You have your backlog of features stakeholders have requested? What kind of delivery commitments do you feel safe to make? What commitments might not be wise? How can you plan that effectively?
Release planning tries to peer into the future and establish some sense into future progress. We will look at: - some simple (but effective) tools to both plan and communicate key goals and constraints. - different strategic approaches to managing the release and backlog - the concept of velocity and its appropriate use in longer term planning But of course, first you need to make your plan. For real*. * Okay, as real as it can get in a conference session.
Developing a Realtime Android Game with Scala - Lessons Learned
We completed our 11 month journey of creating a realtime space shooter for Android using Scala programming language. We did the project in our freetime and you can check out the end result at www.punchwolf.com/scawar . This presentation takes a dive in to those 11 months of intense development and takes a look at things we think went well and things we would definitely do differently if we were to start again from the beginning. We will look at how functional programming fits writing games from the perspective of Scala language and how well they suit the Android platform. We will discover what challenges does a freetime, multi-location project present to agile methods. We will also present some hard-earned lessons on planning, motivation and game optimizing.
Technical excellence, meaning e.g. quality code, sound architecture, good test automation and coverage, continuous integration and continuous deployment is the pre-requisite of sustainable software development. Sustainability of software development is essential for improving the ROI and extending the life cycle of software products and services. In my talk I will argue that technical excellence is impossible to buy from a software vendor and impossible to enforce in contractual terms. The other side to this subject is my second argument: the only way to ensure technical excellence is to have a skilled and motivated team that takes responsible of it, and giving that team the responsibility and means to ensure technical excellence. I'll also talk about options how to achieve this. The talk will be provocative. I will back my arguments with personal experiences as well as with anecdotes and research.
Technical as it is, software is still created by human beings. Most of the time, several people form a team to deliver a certain project. What factors contribute to the success of the team? Obviously, external factors such as a good work environment and team members with proper skills play an important part. There is however one more essential ingredient, abstract and hard to measure: how well the team manages to work together, resolve conflicts and communicate, both internally and with the customer. This talk will open your mind to how important effective communication is for the success and well-being of a software development team. You will learn how to improve communication using a set of ground rules that can help any work group reach the next level of collaboration.
In his presentation Juha will share his thoughts on how to draft agile contracts so that they make it possible to achieve the "win" scenario, the delivery of the best value to the customer, as opposed to the traditional waterfall contracts drafted solely with the "lose" scenario in mind. He will tackle the typical pain points an agile software development company faces when negotiating contracts with lawyers and procurement people who almost without exception have waterfall mindsets. He will draw from his past experience of advising the other side of the table to explain what a customer should be looking for in an agile software development contract. And he will share some of his thoughts on how lawyers tend to draft over-complex contracts for relatively non-complex matters and suggest a better way
Building the Right Thing: Developer Point-of-View
- by Markus Hjort
Business Model Canvas, MVP, Pivot, XLM, continuous deployment. Many terms have been coined by the Lean Startup movement. Most of these practices radically change the way businesses do their job - making them more agile as a result. The idea is to make sure we are building the right thing. But what do I care as as a developer? I've noticed that on a daily basis, many "building the right thing" decisions are made when the team members play the implementation of the design by ear. Many interesting discoveries are often stumbled upon during this process. All of these small decisions have a huge impact on our capability to build and launch new products.
In this talk I will explain why it is important for all the developers to have the "right" mindset. After all they are key people in making sure the ship is sailing in the correct direction at all times. All the small actions taken during the course are counted. I will share real cases, propose solutions and present pitfalls to avoid.
DevOps - the trendy word what is so hard to explain. At this presentation we throw away all the misunderstandings of DevOps and try to understand what it actually is. We jump out of commonly known DevOps tools and practices and look at the bigger picture. Talk goes trough what the DevOps -culture is and what it means for company. How it can improve the whole company work more efficiently and achieve more. And most importantly - how all, not just developers and operation, got to change
The buyer lacks software expertise, and the supplier lacks domain expertise — what to do? The traditional solution is to define clear responsibilities and handovers... but we know how well *that* works. The other solution is to pull the customer closer to the supplier... better but not perfect. How about the third option: joining forces, involving the full value chain, and applying joint incentives? In other words: real collaboration on like terms. What does this mean for the customer? What does it mean for you? Come and find out!
In several years of working with agile teams and organisations I learned various approaches to coaching that might seem counterintuitive at ﬁrst: how to speed up the change process by slowing down the coaching pace, how leadership should be approached systemically rather than individually, how coaching teams can be done with one-to-one interventions and many more. In this interactive presentation I will share these ﬁndings and discuss them with the audience.
Some say, only small co-located teams with little integrations and ability to control their environment can truly become agile. Many of the success stories available are about these teams and them growing bigger over time. This presentation is all about turning a large organization with complex structure into more agile. You will not hear how to reach 200 % improvement in productivity or a listing of “best practices”. However you will hear how a company coming from traditional waterfall(ish) environment can change and improve daily work. It is all about over 650 ICT experts, some with more than 25 years of experience, are changing behavior and learning new tricks. It is all about those ICT experts working even closer than before with our business experts to implement the right changes at the right time.
Welcome to Vincity
Somewhere deep in the concrete jungle of Hervanta is Vincity. It's a home for passionate and agile Vincitizens, and headquarters of software company Vincit Oy. Vincity has unorthodox laws, and strange things happen often.
You are invited to an exclusive virtual tour. Come and see why Vincit has been so prosperous - hot presentation guaranteed!
AgiES is a two-year TEKES-funded research project of University of Turku, Finnish Institute of Occupational Health and several industry partners. Our objective is to investigate the use of agile methods in embedded systems development in terms of efficiency and well-being at work. The key challenge is to let software developers, hardware designers, mechanical engineers and other practitioners work seamlessly together. Now and then we hear a rumor, that there is nothing new in applying agile in embedded development and therefore the mission is already accomplished.
We deny the claim, present the evidence and encourage the audience to proof us wrong!