United States 
Ryan will be presenting the following session
-
keyboard_arrow_downRyan Singer - Shaping the Work: Assigning Whole Projects, not Tasks
45 Mins
Keynote
Intermediate
As software teams start to grow, some common struggles appear:
- Team members feel like projects go on and on, with no end in sight.
- Product managers can’t find time to think strategically about the product.
- Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”
We saw these challenges first-hand at Basecamp as we grew from four people to over fifty.
In this talk, Ryan will share how the Basecamp team operates and talk about his new book that will help us Stop Running in Circles and Ship Work that Matters.
1. What got you started/interested in modern software development methods?
Design was important to us at the company where I worked. Traditional "agile" methods didn't explain how to integrate UI design into the process. And those processes usually assume that the UI and tasks are defined up-front at the beginning of the sprint instead of worked out iteratively.
2. What do you think is the biggest challenge faced by the software product engineering community today?
The huge growth of the software industry means most people are new and don't have a lot of experience. We're like the auto industry before Toyota. There are lots of quality issues, production problems, and not many good models to follow for how to create a really effective development process from idea to design to deployment.
3. What do you think are the most exciting developments in software product engineering today?
Tech-wise, the return to server-side rendering (eg. Hotwire) is exciting because it allows one or two programmers to build whole applications with fewer moving parts. Functional programming principles are also starting to become more widely known and lead to software designs that are easier to understand.
4. Why did you choose the topic(s) you will be speaking about at the conference?
I'm seeing a lot of teams who work off of long lists of tickets all the time. This has two big problems. One is, most of the work in the real world starts to appear after you start the project ("discovered" tasks). So the tickets don't represent the actual work going on. The other problem is, when people work from tickets, it's hard to see the big picture of what the whole project is supposed to do to be successful. I've seen lots of teams make huge improvements in what they ship by defining the rough shape of the whole project and letting the individual contributors come up with the tasks for themselves as they go.
5. What are some of the key takeaways from your session(s) at Agile India?
There's a huge difference between the work we imagine we have to do when we first create tasks and the actual work we discover we have to do after we start trying to build. If we are too focused on tasks and tickets, we lose the bigger picture and projects can spiral out of control. By shaping the project up front at a higher level, we can define the boundaries of what is really important and not important, and the team can make decisions along the way to "hammer" the scope back so it fits in the time allowed.
