teams
Articles
 |
Embracing Change and Complexity Louis J. Taborda explains that in order to be successful, we need to be able to embrace both change and complexity while being agile. The more quickly we develop software and the greater the sophistication of the solutions we build, the more difficult it is to maintain agility. |
Louis Taborda
April 19, 2012 |
 |
Goal, Goal, Who's Got the Goal? Don Gray explains why software development teams need three common goals: long term, mid term, and short term. These goals focus a team and provide the glue that holds the team together. |
|
 |
Management Myth #3: We Must Treat Everyone the Same Way One of the biggest management myths is, “I must treat everyone the same way.” Nothing could be further from the truth. Everyone has different goals for their career, and those change over the course of a career. |
|
|
Heard and Valued: Three Short and Useful Bits of Advice for Improving Your Leadership Skills Yogi Berra famously said, “You can observe a lot just by watching.” In this article, Payson shares some of what he’s learned about leadership just by listening. Learn how transparency and iterative improvement can maximize the results of great leadership. |
||
|
On Beauty, Quality, and Relativity The saying “beauty is in the eye of the beholder” rings true whether you’re staring at a centuries-old painting, listening to a busker’s music reflect off the tiles in a subway station, or testing software. It’s one thing to evaluate quality, but how do we evaluate how we evaluate quality? |
||
 |
We're Not "Special" Often, when I comment on someone's blog post or respond to a tweet with a story about how my team succeeded with some practice, someone replies, "Yeah, but your team is special." I interpret this as meaning, "You're a presenter and book author. You must be an expert, so of course your team can do anything." This frustrates the heck out of me. |
|
|
Management Myth #2: Only ‘The Expert’ Can Perform This Work How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available? What happens on your project? Does it wait until The Expert is available? |
||
 |
Integrating Games to Change Behaviors, Part 2 Training people and introducing new ideas requires more than just clear, factual explanations or theorems. Brian Bozzuto explores how games, simulations, and other exercises play an instrumental role in helping people be comfortable enough with new ideas that they choose to put them into practice. |
|
|
Agile Lifecycles for Geographically Distributed Teams: A Case Study In this case study of a distributed agile team, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. |
||
|
Agile Lifecycles for Geographically Distributed Teams: Using a Project Manager with Kanban, Silo'd Teams This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California. This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban. |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
AgileConnection is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.